Vector Databases Without the Jargon

What does a vector index actually do?

Embedding turns every chunk of text into a row of numbers — typically 768, 1,024 or 1,536 of them. Search after that is geometry: which row of numbers is closest to the one for your question. That step is what the embeddings and vector search explainer covers in more depth.

The problem in one sentence: if you have a million chunks, you would have to compute a million distances on every question. The vector index exists so that you do not have to.

Three approaches exist, and it is worth knowing what each of them gives up:

The graph-based solution is the most widely used, and the authors' own analogy makes it easy to grasp: it is like a multi-storey map. The top floor has few points and long jumps; going down, there are more points and shorter steps. The search starts at the top, makes big jumps, then closes in more and more finely.

The thing to take away: all of them are approximations, except the first. Vector search does not guarantee that it gives you the best result — only that it very quickly gives you a very good one. That is usually enough, but not always; that is what the hybrid search article is about, with the numbers.

The memory calculation that settles the question

Here is the most important table in the article. [Own calculation] from the vendor's official capacity-planning formula, with 1,536-dimension vectors:

vector / chunk = 1,536 dimensions × 4 bytes = 6,144 bytes ≈ 6 KB
index  / chunk = 16 × 2 × 4 bytes × 1.2     = 154 bytes

That single table tells you where the pain thresholds are:

• 10 thousand vectors: 75 MB. Fits anywhere. Nothing special needed.
• 1 million vectors: 7.5 GB. No longer fits a small virtual machine, fits a normal server. This is where quantization starts to matter.
• 10 million: 75 GB. Here memory becomes the main cost item, and here disk-based indexes start to make sense.
• 100 million: 755 GB. Keeping that in memory for sensible money is no longer a viable route.

And look at the index column: in this example it is everywhere 2–3% of the total size — in the vendor's own 768-dimension example it is 5%. The "vector indexes are expensive" myth comes from confusing the index with the vectors.

Two multipliers that most often get left out of planning: replication doubles the memory, and the dimension count multiplies it linearly. The latter is the strongest one you can freely set — switching from 1,536 to 512 dimensions cuts memory to a third.

Quantization brings it down further: half precision to half, eight-bit quantization to a quarter — with practically zero accuracy loss, according to the vendor's measurement. Quantization itself is the subject of the quantization piece, in detail.

Do you even need a separate database?

This is the developer reader's real question, and in 2026 the answer has changed.

There is a choice at all because vector search is a capability, not a kind of database. The same relational database that already holds the company's real data can learn it: Postgres has an extension called pgvector that gives it a vector column type and the nearest-neighbour indexes to go with it. That way the text chunk and its embedding sit side by side in one table, and the search is plain SQL — in the same query as the metadata filter.

And pgvector has caught up. The July 2026 release does graph-based and cluster-based indexes, eight-bit and binary quantization, half precision — and since late 2024 it also does the thing that was the oldest complaint against it: search combined with filtering, where too few results used to come back.

There is one important limitation worth knowing up front: the base vector type indexes at most 2,000 dimensions. The larger embedding models in common use today produce 3,072 dimensions — that does not fit. There are two ways out: the half-precision type (up to 4,000), or reducing the number of embedding dimensions, which the larger models support.

YOU DO NOT NEED A SEPARATE VECTOR DATABASE IF

- your Postgres is already there and the vectors fit;
- the size does not yet justify an index (up to a few
  hundred thousand, exact search is often enough);
- metadata filtering is the main operation - relational
  filtering plus a small vector set is simpler.

YOU DO NEED ONE IF

- the memory requirement exceeds your machine, and
  disk-based or tiered storage is the only way;
- queries per second are the primary concern;
- you need native hybrid search, in one index.

Transactions and JOINs are something a relational database can do and a vector database cannot — and that consideration is missing from most comparisons.

What does the measurement say?

There is a public comparison of seven systems at the same monthly budget, on one million vectors. Four rows from it:

Two things are worth reading off it. One: at the same budget there is an order-of-magnitude difference in query capacity — from 1,147 to 13,316.

The other one matters more: the fastest system does not give the best results. System C works with three times the latency, but delivers the highest recall. If what counts is finding the correct answer — and in RAG that is exactly what counts — then the benchmark winner is not necessarily your winner.

(The measurement was run by one of the players, on their own open-source framework, and their own product wins. The code is open and there is an independent variant. The date of the measurement is not shown on the page — that in itself is a caveat.)

What you cannot conclude from it: how many times slower pgvector is than the dedicated systems. I found no independent 2026 measurement of that — the extension does not even appear in the comparison cited.

Four pricing logics that cannot be compared

This is the most practical part of the article, because provider price lists are not comparable:

And the practical consequence most calculations leave out: the monthly minimum on entry-level plans runs between $16 and $250. A ten-thousand-document knowledge base consumes a fraction of that. The minimum fee is your real cost, not the consumption — meaning a small system is disproportionately expensive.

The market in 2026: what lives, what disappeared

This chapter is here because this sector changes faster than any other, and writing about it from memory is guaranteed to be wrong.

Gone as a standalone product: one of the early players was acquired in June 2024 by a large model developer, and existing users were given 90 days to move to something else.

A rename that is a trap: the company behind one time-series database changed its name in June 2025 — but its extensions did not. Anyone writing from memory either uses the old company name or renames the extension too. Both are wrong.

Acquired but still alive: two well-known embedding and re-ranking developers also changed hands, in February and October 2025. The models stayed available.

And the flagship of the category is in trouble: it changed its chief executive in September 2025, and according to press reports it is weighing a sale. (That is a [press report], not a company announcement. The product works in September 2026, it is available, it has a price list — I checked that.)

The wider picture that explains all this: the incumbents — relational databases, search engines, cloud platforms — have all added vector search. That took away the main argument for introducing a whole new database.

Latency: two numbers from the same system

One provider's own data, on the same ten-million-document dataset:

A sixtyfold difference, inside the same system. It shows nicely that an architecture is not equally cheap for every type of operation — and that if you are planning hybrid search, the text side may be your bottleneck.

The how-to

1. WORK OUT THE SIZE BEFORE YOU CHOOSE
   chunks × dimensions × 4 bytes. If the result
   is under one gigabyte, do not complicate it.

2. LOOK AT WHAT YOU ALREADY HAVE
   If Postgres is running, it probably handles it.
   One database fewer, transactions on top.

3. CHECK THE DIMENSION LIMIT
   The 3072 dimensions of big embedding models do
   not fit the base vector type when indexed.

4. DIMENSION COUNT IS THE STRONGEST MULTIPLIER
   1536 to 512: memory drops to a third.
   Try this before you change architecture.

5. QUANTIZATION FIRST, A BIGGER MACHINE AFTER
   Eight-bit quantization takes memory to a quarter,
   with barely measurable accuracy loss.

6. DO NOT PICK THE FASTEST, PICK THE MOST ACCURATE
   In the measurement the fastest system did not
   give the best results. In RAG the result counts.

7. WATCH THE MONTHLY MINIMUM, NOT THE UNIT PRICE
   On a small knowledge base the minimum is the bill.

8. WHAT YOU PICK TODAY MUST NOT BE IRREVERSIBLE
   In two years this sector has seen a shutdown, a
   rename, three acquisitions and a leadership change.

The eighth point is not timidity in this category. Keep the raw chunks and the metadata in your own storage as well: you can re-run the embedding any time, but you cannot get your documents back out of a service that has shut down.

Common misconceptions

• "The vector index eats a lot of memory." According to the official formula the graph is a few per cent of total memory. It is the vectors that eat it.
• "Vector search finds the best result." Only exact search guarantees that. The fast indexes all approximate.
• "I need a vector database if I am building RAG." Up to a few hundred thousand, your existing database is usually enough. This is a scaling tool, not an entry ticket.
• "The benchmark winner is the best choice." In the same measurement the fastest system gave lower recall than one with three times the latency.
• "Storage is the main cost." Storage is pennies. The monthly minimum and the model cost of answering are the real items.
• "I decide this once and I am done." In two years this sector has seen a shutdown, a company rename and several acquisitions. Plan an exit route.

What to take away

The maths of vector search is simpler than the marketing around it. What you need to know: memory grows with the vectors, not with the index, the dimension count is your strongest lever, and up to a few hundred thousand you often need nothing special at all.

Before you choose, it is worth working out a single line: chunk count × dimensions × 4 bytes. If the result is under one gigabyte — and with ten thousand documents it usually is — then the question is not which vector database to pick, but whether you need one.

And one thing that matters more than the technology choice: keep your raw text. The embedding can be recomputed; a knowledge base rescued from a discontinued service cannot. Why and how to chunk at all is what the chunking post covers, and for the whole picture there is the RAG explainer pillar article.