104 | Vespa | Attribute Store

Why Can Amazon Show “Only Products Under $100” Instantly?

Imagine you’re shopping online. You search for:

wireless headphones

The site returns 2 million matching products. Then you click:

Price < $100

The results update almost instantly. Next you select:

Category = Electronics

Again, instant. Then:

In Stock = True

Still instant.

At this point, a natural question arises:

Is the search engine scanning millions of products every time I click a filter?

If it did, every filter click would take seconds. Yet modern search systems respond in milliseconds. How?

Finding Documents Is Not the Hard Part

Most people first learn about the inverted index. The inverted index answers questions like:

Which documents contain the word “headphones”?

That’s great for text search. But now imagine we already have 2 million matching products. The user isn’t asking for text anymore.

They’re asking:

price < 100

or

rating > 4.5

or

category = laptop

These are not text lookups. They’re data lookups. And that’s where a different part of Vespa takes over.

Meet Vespa’s Secret Weapon

Inside Vespa’s Content Cluster lives something called the Attribute Store. Unlike the inverted index, which focuses on words and terms, the Attribute Store focuses on Field values.

Think about a product catalog:

A naive design might store each product as a complete record:

Product 1:
  price=799
  rating=4.6
  category=phone

Product 2:
  price=1299
  rating=4.2
  category=laptop

To find all products under $1000, you’d have to inspect every product. That doesn’t scale.

Vespa Organizes Data Differently

Instead of storing values row by row, Vespa stores attributes column by column. Conceptually:

Price Column
799
1299
599
1999
899
...

Rating Column
4.6
4.2
4.8
4.1
4.7
...

Category Column
phone
laptop
phone
laptop
tablet
...

Notice what’s happened.

• All prices sit together.
• All ratings sit together.
• All categories sit together.
• Why does this matter?

Because when a query asks:

price < 1000

Vespa only needs the price column. Nothing else. It never touches ratings. It never touches categories. It never touches descriptions.

The Library Analogy

Imagine a library with millions of books.

Someone asks:

“Show me every book published after 2020.”

One librarian searches every shelf manually. Another librarian already keeps a sorted list of publication years. Who wins? Obviously the second one. The Attribute Store works exactly the same way.

Instead of repeatedly searching documents, Vespa builds structures that already know where values are located.

The Real Trick: Specialized Lookup Structures

The most interesting part isn’t that values are stored in memory.

It’s that Vespa builds different lookup structures depending on the type of question being asked.

Scenario 1: Finding Cheap Products

A user asks:

price < 1000

Now imagine all prices stored in sorted order:

299
599
699
799
899
1099
1299
1599
1999

Instead of checking every product, Vespa performs something much smarter. It jumps directly to the boundary. Similar to how you’d find a word in a dictionary. This allows Vespa to answer range queries extremely quickly.

The result might be:

docIds = [8,3,7,1,5]

These are the matching products. No full scan required.

Scenario 2: Sorting by Rating

Now the user says:

Sort by rating descending

A naive system would sort millions of products on every query. That would be expensive. Instead, Vespa already maintains structures optimized for sorting.

Conceptually:

4.8 → Product 3
4.7 → Product 5
4.6 → Product 1
4.5 → Product 9
...

Finding the top-rated products becomes almost trivial. Vespa simply starts from the top.

Scenario 3: Category = Laptop

This query is different. We’re not looking for ranges. We’re looking for equality.

category = laptop

For this, Vespa uses a hash-based lookup.

Conceptually:

phone  → [1,3,7]
laptop → [2,4,6,9]
tablet → [5,8]

The answer already exists.

A lookup immediately returns:

[2,4,6,9]

No searching required.

Scenario 4: Only Show Products In Stock

Now consider:

in_stock = true

This seems simple, but it happens constantly in e-commerce. Vespa uses a remarkably efficient representation called a bitmap.

Imagine one bit per document:

1 1 1 1 1 0 1 1 1

Where:

1 = in stock
0 = out of stock

Checking millions of documents becomes a series of extremely fast CPU operations.

Where the Magic Happens

Now let’s combine filters:

category = laptop
AND
in_stock = true

The category lookup returns:

[2,4,6,9]

The stock bitmap returns:

1 1 1 1 1 0 1 1 1

Vespa intersects these structures and immediately finds:

[4,9]

Only two products match. This is why complex filtering can remain fast even across millions of documents.

Why Everything Lives in Memory

Notice something important. The Attribute Store is designed to avoid disk access during queries. If every filter required reading files from disk:

Filter
   ↓
Disk Read
   ↓
Filter
   ↓
Disk Read

latency would explode. Instead, Vespa keeps these structures in RAM. The query can operate directly on memory-resident data. That’s the difference between milliseconds and seconds.

The Bigger Picture

Earlier we saw how the inverted index answers:

Which documents contain this text?

The Attribute Store answers a completely different question:

Which documents satisfy these conditions?

Together they form a powerful partnership.

Search:
"wireless headphones"
          ↓
Inverted Index
          ↓
2 million matches
          ↓
Attribute Store
(price < 100)
(category = electronics)
(in_stock = true)
          ↓
Filtered candidates
          ↓
      Ranking
          ↓
      Results

Neither structure alone is enough. The inverted index finds candidates. The Attribute Store narrows them down efficiently.

The Hidden Reason Vespa Scales

Most people assume search engines become fast because their hardware is powerful. The real reason is different. Vespa spends time organizing information before queries arrive.

By the time a user clicks:

Price < $100

the answer is already partially prepared.

Instead of asking:

“Which products satisfy this condition?”

Vespa is really asking:

“Which pre-built structure can answer this condition fastest?”

That shift — from searching data to navigating precomputed structures — is what allows Vespa to handle millions of documents while still delivering near-instant filtering, sorting, grouping, and ranking.

Hawkeye Overview

Deep Dive Summary