Choosing an Enterprise Vector Database: Benchmarks, Deployment Models, and TCO

Almost every published vector-database comparison opens with a latency table. Treat those tables as unusable unless they name the dataset, the dimensionality, the index parameters, the recall target, the hardware, and who paid for the run. Approximate nearest-neighbor search trades recall against latency and memory, so a latency figure quoted without its recall figure carries no information.

Any of those numbers moves by changing one index parameter, which is why "vendor A: 9.5 ms, vendor B: 12 ms" tables travel so well and mean so little. That is not a counsel of despair, because the decision is still tractable — it just gets made from different evidence. Every serious vendor publishes how its index consumes memory, what its compression options trade away, which deployment models it supports, and what its meter actually charges for. Those documents are first-party, specific, and comparable, and they determine cost and operability far more than any latency benchmark would. This comparison works from them.

Why the published benchmark numbers do not decide this

The reference academic benchmark for this space is ANN-Benchmarks, described by its authors as "a tool for evaluating the performance of in-memory approximate nearest neighbor algorithms" in which "algorithms are compared with respect to many different (approximate) quality measures."^[1] Two things follow. First, it benchmarks *algorithms*, not managed services — it says nothing about a vendor's replication behavior, filtering semantics, multi-tenancy, or bill. Second, and more usefully, its headline finding is that "very different approaches to k-NN search yield comparable quality-performance trade-offs."^[1] If well-implemented approaches converge on similar quality-performance curves, then the ranking you are shopping for is mostly noise, and the differentiators that remain are operational and commercial.

The number that actually drives cost: memory per vector

HNSW is the default index almost everywhere, and its properties explain the shape of every bill in this category. The original paper describes a multi-layer proximity graph in which "starting search from the upper layer together with utilizing the scale separation boosts the performance compared to NSW and allows a logarithmic complexity scaling."^[2] Logarithmic search is what makes it fast; the graph that delivers it is what makes it expensive, because the vectors and their links want to be resident in RAM.

Two vendors publish sizing formulas, and comparing them is instructive because they disagree on the multiplier while agreeing on the shape. Weaviate's docs give a rule of thumb of "Memory usage = 2 * (the memory footprint of all vectors)," worked through as one million 384-dimensional float32 vectors at 384 × 4 B = 1,536 B each, totaling 1.5 GB of raw vectors and therefore roughly 3 GB in practice; the same page offers a tighter estimate that prices the graph links explicitly — "if maxConnections is 64 and the other values are the same, a more accurate memory estimate is 1e6 * (1536B + (64 * 10)) = 2.2 GB."^[3] Qdrant publishes `memory_size = number_of_vectors * vector_dimension * 4 bytes * 1.5`, explaining that the "extra 50% accounts for metadata (such as indexes and point versions) and temporary segments created during optimization," and works it through as one million 1,024-dimensional vectors ≈ 5.72 GB.^[4]

Quantization is the lever that moves the bill

Because RAM dominates, compression is where real money is saved — and here the vendor documentation is unusually concrete. Qdrant documents four methods with explicit ratios: scalar quantization "compresses each vector component from a 32-bit float to an 8-bit integer, achieving 4x compression with minimal accuracy loss"; binary quantization "reduces each vector component to one to two bits for up to 32x compression" and is "best suited for high-dimensional, centered vector distributions"; product quantization "enables up to 64x compression when minimizing memory is the top priority"; and TurboQuant "supports up to 32x compression, with strong recall across most embedding models," defaulting to 4-bit encoding.^[5]

Note what the vendor does *not* claim. Its own guidance says to "use Product Quantization if the memory footprint is the top priority and accuracy and speed are not critical," and that TurboQuant should be tested on your data before you commit.^[5] That is the honest framing to carry into your own evaluation: compression ratios are published, the recall cost of each ratio on *your* embeddings is not, and it is the only part of the trade-off nobody can hand you.

The same lever exists elsewhere under different names. Weaviate's docs point to product quantization as a way to "increase the number of vectors you can hold in memory."^[3] Milvus exposes compression as index families rather than a separate setting — IVF_SQ8, IVF_PQ, IVF_RABITQ, HNSW_SQ, HNSW_PQ, HNSW_PRQ alongside uncompressed FLAT, IVF_FLAT, and HNSW, plus disk-resident DiskANN and GPU variants.^[6] pgvector offers a `halfvec` half-precision type and binary quantization, and its scaling advice for a smaller working set is exactly that: "use the halfvec type instead of vector for tables" and "use binary quantization for indexes (with re-ranking for search)."^[7]

Deployment models — the axis that usually decides the shortlist

Before latency or price, most enterprise shortlists are decided by where the data is allowed to live. Every vendor in this comparison now sells more than one answer, and the names differ more than the substance. Qdrant's pricing page defines its three: "Managed Cloud is fully managed by Qdrant. Hybrid Cloud lets you bring your own infrastructure while using Qdrant's management plane. Private Cloud gives you complete control with on-premise deployment."^[8] Pinecone's plan matrix lists Bring Your Own Cloud and private endpoints at the Enterprise tier.^[9] Weaviate's plan matrix distinguishes Weaviate-managed cluster upgrades from a customer-directed option.^[10]

Read the meter, not the headline price

Rate cards in this category are not comparable line by line, because the vendors meter different things: Pinecone bills read and write units plus storage, Weaviate bills vector dimensions plus storage, Qdrant bills the resources a cluster consumes, and Zilliz Cloud bills compute units sized by a performance tier. The useful exercise is not to line the numbers up — it is to work out which meter your workload spins fastest.

Pinecone's documentation deserves a close read for a reason that generalizes: its meter behaves in a way that surprises people. "A query uses 1 RU for every 1 GB of namespace size, with a minimum of 0.25 RUs per query," and — the important part — "parameters that affect the size of the query response, such as top_k, include_metadata, and include_values, are not relevant for query cost; only the size of the namespace determines the number of RUs used."^[12] Query cost therefore scales with how much data you put in a namespace, not with how much you ask for or how tightly you filter. Writes are metered by payload size, at 1 WU per 1 KB for upsert, update, and delete, with a 5 WU minimum per request — so many small writes cost far more than the same bytes batched.^[12]

The pgvector question: when you do not need a vector database

For a large share of enterprise RAG workloads the honest answer is a Postgres extension. pgvector stores vectors "with the rest of your data" and brings "ACID compliance, point-in-time recovery, JOINs" along with it, and by default "pgvector performs exact nearest neighbor search, which provides perfect recall" — you opt into approximation only when you add an index.^[7] For corpora in the low millions on hardware you already run, exact search with perfect recall removes an entire class of tuning problems.

Know the three limits before you commit. Index type: HNSW "has better query performance than IVFFlat (in terms of speed-recall tradeoff), but has slower build times and uses more memory," and unlike IVFFlat it can be built on an empty table because there is no training step.^[7] Dimensions: indexable vectors go up to 2,000 dimensions for the `vector` type, 4,000 for `halfvec`, and 64,000 for `bit` — so a 3,072-dimensional embedding needs half-precision indexing, binary quantization, or dimensionality reduction.^[7] And filtering: "with approximate indexes, filtering is applied *after* the index is scanned. If a condition matches 10% of rows, with HNSW and the default hnsw.ef_search of 40, only 4 rows will match on average" — the fix is iterative index scans, but a team that does not know this ships a heavily filtered RAG query that quietly returns almost nothing.^[7]

How to run the only benchmark that counts

Because the published numbers do not transfer, the evaluation has to be yours. It does not need to be elaborate — it needs to be honest about the four variables that any vendor number silently fixes: your embeddings, your scale, your recall target, and your filter patterns. Fix a recall floor first (measure it against exact search on a sample, which is what pgvector gives you for free), then compare candidates on latency and cost *at that floor*. A vendor that is fastest at recall 0.80 and a vendor that is fastest at recall 0.95 are frequently not the same vendor.