One million 1,536-dimension float32 vectors — the same shape OpenAI's text-embedding-3-large produces — weigh roughly 6.1 GB before HNSW graph overhead. Ten million of them need 60 GB, all RAM-resident. That arithmetic, not vendor selection, now sets the cost of vector search at scale, argues database engineer Itamar Syn-Hershko, founder of BigData Boutique and a former co-manager on the CLucene search engine project.

Syn-Hershko's column, published this week, makes a blunt case: the standalone vector database category has folded into the engines teams already run. Pinecone named the segment when it launched its managed service in 2021; Milvus, Weaviate, and Qdrant arrived in the same window. Back then, the pitch made sense — general-purpose databases had no good approximate nearest-neighbor (ANN) index.

The incumbents closed the gap fast.

• Elasticsearch shipped k-NN over HNSW on top of Lucene's implementation.
• OpenSearch has carried a k-NN plugin since its 1.0 release.
• pgvector added HNSW in 0.5.0 in August 2023, turning stock Postgres into a credible vector store.
• MongoDB Atlas Vector Search hit GA in December 2023.
• Redis exposed vector similarity in RediSearch 2.4 back in 2022.
• ClickHouse's HNSW vector similarity index reached general availability in 25.8.

The same algorithm shows up everywhere because it delivers 95+ percent recall without a rebuild step.

What actually drives the cost?

Memory. Full stop.

HNSW is a graph that demands pointer-chasing traversal, and that traversal is only fast when both the graph and its vectors sit in RAM. The moment nodes spill to disk, latency gives way to page faults rather than distance computation.

OpenSearch documents the per-vector footprint as 1.1 × (4 × dimension + 8 × M) bytes. The 4 × dimension term is the float32 vector itself. The 8 × M term is per-node connection overhead. The 1.1 is roughly 10 percent slack. Dimensionality, not document count alone, sets the hardware tier.

Graph structure compounds the raw size. HNSW stores neighbor lists at every layer, so the index can run 2–5× the size of the raw vectors, where IVFFlat's flat per-cell storage stays near 1.1×.

The recall-versus-throughput curve is steep and non-linear. Pushing HNSW from 95 percent to 100 percent recall on standard ANN benchmarks can cost roughly 7× in throughput. Syn-Hershko's take: chasing the last two points of recall is usually the most expensive thing in the whole pipeline, and rarely the thing users notice.

Which levers actually bend the curve?

Quantization and tiering, mostly orthogonal to vendor choice. The numbers behind each technique are concrete:

• Lucene's int8 scalar quantization cuts memory by about 75 percent and keeps raw vectors on disk for rescoring.
• Binary quantization reaches 32×. Qdrant reports 0.98 recall@100 on 1,536-dim OpenAI embeddings with 4× oversampling.
• Elasticsearch's Better Binary Quantization shrinks a 138M × 1024-dim dataset from roughly 535 GB to about 19 GB.
• Microsoft's DiskANN indexes a billion points on a single 64 GB machine plus SSD at 95+ percent recall, serving thousands of queries per second.
• Amazon's S3 Vectors targets up to 90 percent lower cost on large vector datasets, trading latency for price.

OpenSearch's disk-based mode showed p90 latency of 96 ms versus 24 ms for the in-memory path. Inside a multi-second agentic reasoning loop, that's invisible. For interactive autocomplete, it's disqualifying.

Where does self-managed vs managed really fall?

Not on capability. Both can run HNSW, both can quantize, both can tier. The line falls on who owns three things: the memory-sizing math, the rescoring and latency cliff, and the routing between hot and cold tiers.

Managed services absorb the provisioning problem. They size the RAM, isolate vector traffic onto dedicated nodes (MongoDB shipped dedicated Search Nodes with its Vector Search GA for exactly this reason), and hide the cold-tier fetch behind a single API. You give up some knobs. You pay a margin. You stop owning the failure modes.

Self-managed gives you every knob and the bill that comes with using them wrong. You set M, ef_construction, ef_search. You choose the quantization scheme and oversampling ratio. You decide the rebuild cadence. You also inherit cold queries that page-fault on every traversal step, recall that drifts as data distribution changes, and fan-out math that turns over-sharding into a tail-latency trap.

Syn-Hershko's framing: pick the engine for the workload, not the other way around. A team with a sub-20 ms interactive budget and a small ops crew usually wants the managed hot tier. A team that already runs Postgres or OpenSearch at scale and has the headcount for capacity planning will squeeze more out of self-managing.

What's next?

The category Pinecone created in 2021 now lives as a column type in Postgres, the Lucene engines, ClickHouse, MongoDB, and Redis. The dollars still move on how many vectors you hold in RAM and how aggressively you compress them. Expect the next round of cost competition to land on tiering policy, oversampling ratios, and disk-resident recall curves rather than on the algorithms themselves.