Vector Indexes in OLAP Engines: 2025 Is Where Search Ate Analytics

The unification nobody saw coming

For about two years, the prevailing wisdom in AI infrastructure decks was that you needed two databases. One for analytical data — the warehouse, the lakehouse, the columnar engine of your choice — and a second, dedicated vector database beside it, holding embeddings of the same data and serving similarity search to a RAG pipeline. The split made sense in 2022 because warehouses had no concept of a vector and vector databases had no concept of analytical SQL. So you ran both, paid double for essentially the same rows, and wrote glue code to keep the two sides in sync.

By the second half of 2025 that architecture had quietly stopped being the default. The reason wasn't that the vector-database vendors got worse — they didn't. The reason was that every warehouse-class engine added a native vector type and a native HNSW or IVF index, and once that happened the math on running two systems stopped working for the typical case. Why pay for a separate index in a separate database — its own auth, its own backup, its own SDK, its own sync pipeline — when the column already lives in the warehouse and the engine will index it for you in one statement?

The deeper realization was that embedding search is not actually a different shape of workload from a column aggregate. It's a scan over a column of fixed-size float arrays with a distance function applied per row and a top-k operator on top. That's analytical SQL. The literature had been pretending it was a new database category. It wasn't. It was a new function, and warehouses are very good at adding functions.

What HNSW, IVF, and DiskANN actually are

HNSW — Hierarchical Navigable Small World graphs — is the algorithm most engines reach for first. The idea, from Malkov & Yashunin's 2016 paper, is to build a multi-layer proximity graph where each layer is a sparser sample of the one below it. Start at the top, greedily walk toward the nearest neighbor at that layer, drop down, repeat. The hierarchy gives logarithmic-ish search on a structure that at the bottom layer looks like a small-world graph where most nodes are reachable from most others in a few hops. HNSW is the default in pgvector, DuckDB VSS, and ClickHouse for one practical reason: it's fast to query, the recall curves are predictable, and the implementations in usearch and hnswlib are genuinely good.

IVF — Inverted File index — is the classical alternative. Cluster your vectors into k coarse Voronoi cells via k-means, store the assignments as (cell-id → list of vector-ids), and at query time only scan the few cells closest to the query vector. IVF is what BigQuery picked. The win: the index is small, builds fast and parallel on a warehouse-style engine, and recall tunes cleanly via probed cells. The loss versus HNSW is usually a worse recall-at-low-latency point in memory, but a much better story for out-of-core scans where you'd rather skip cells than walk a graph.

DiskANN is Microsoft Research's 2019 NeurIPS work on making graph indexes work from SSD instead of RAM. It uses a single-layer Vamana graph on disk, keeps a heavily quantized copy of the vectors in memory for traversal, and only hits SSD for the final exact-distance comparisons against full-precision vectors. The point: you can index a billion vectors on a 64 GB workstation with a cheap SSD and still get 95% recall at single-digit-millisecond latency — territory pure-RAM HNSW can't reach without a much bigger server. Most warehouse-side implementations don't ship DiskANN yet; the algorithm is harder and the operational story (cold-cache penalties, SSD wear) is more delicate.

The 2025 shipping schedule

The fastest way to see how saturated this got is to list what shipped, when, and with which algorithm.

• Snowflake — VECTOR data type and the cosine / L1 / L2 / inner-product similarity functions went GA on May 16, 2024. The VECTOR type takes an element type (INT or FLOAT) and a dimensionality up to 4,096. Cortex embedding functions ship in the same surface, so embed-and-store is one SQL call.
• DuckDB — The VSS extension launched May 3, 2024 with HNSW indexes on the fixed-size ARRAY type, built on usearch. A major performance rev landed October 2024: a new HNSW_INDEX_JOIN operator, better cardinality estimates, and a buffered build pipeline that saturates CPU on many-threaded machines. Persistence still has caveats (the docs are explicit), but for embedded analytics it's the easiest "just put it in your warehouse" experience around.
• pgvector 0.8.0 — Released October 30, 2024. Headline change: iterative HNSW scans for filtered vector queries, plus a real cost-model upgrade so the planner stops mispicking the index under a selective WHERE. AWS publicly measured up to 9× query speedup and 100× better filtered-search recall versus 0.7 on Aurora Postgres. pgvector keeps IVFFlat alongside HNSW — useful when you want a cheaper build at the cost of some query speed.
• BigQuery — Vector search went GA on September 27, 2024 with the VECTOR_SEARCH function and an IVF implementation. The IVF-over-HNSW choice fits BigQuery's design: partition-friendly, parallel build inside the existing query engine, graceful degradation when the table is too large to hold an HNSW graph in memory.
• ClickHouse — Approximate vector search lived as an experimental feature for years (history goes back to issue #52552 in 2023) and finally hit GA in version 25.8 in August 2025. HNSW on usearch, with binary / int8 / bf16 quantization, pre- and post-filter modes, a fetch multiplier for recall control, and an index-only read path.
• Apache Iceberg — Still a proposal, not a feature. The "build full-text and vector index for iceberg" issue opened March 25, 2025 and is the most-watched piece of the v4 conversation. The interesting part isn't "add an HNSW file" — it's whether the table format itself should grow a generic secondary-index slot in metadata that engines can populate with HNSW, IVF, BM25, or something not yet invented.

Six platforms, six independent decisions in roughly an 18-month window, all converging on the same answer. That's a market consensus, not a hype cycle.

The benchmark sleight-of-hand

Every vendor blog comparing vector indexes shows you the same chart: recall@10 on the y-axis, queries-per-second on the x-axis, a single curve per algorithm, on a million-vector synthetic dataset (usually SIFT1M or a GloVe slice). The curves look smooth, the winner looks obvious, and the chart conveniently doesn't tell you what happens at the scale you actually run.

The part everyone undercounts is that recall and latency are workload-dependent in a way the synthetic benchmarks hide. At 10M vectors with a realistic filter selectivity, HNSW's recall holds up nicely but its latency tail blows out as you fight the post-filter combinatorics. IVF's recall is more sensitive to the probe count but its tail is flatter because cluster-skip is well-bounded. Get to 100M vectors and the in-memory assumption underneath HNSW starts breaking — you either shard the graph or you switch to a disk-backed approach like DiskANN. None of that shows up in the SIFT1M chart.

The honest reading is this: if you're inside the vendor's benchmark conditions — in-memory, no filter, modest dataset — HNSW typically wins. If you're outside those conditions, the answer depends on a lot of things the chart isn't telling you. Pick whichever index your engine ships first, measure on your data, and don't believe any recall number you didn't generate yourself.

Where dedicated vector DBs still win

This is the part of the story where most takes go too far. The narrative wants to be "warehouses ate vector databases," and the warehouses certainly took the easy 90% of the workload. But there's a real 10% where Pinecone, Weaviate, Qdrant, and Milvus are still the right answer, and pretending otherwise would be bad engineering.

• Billion-scale corpora with hard tail-latency SLAs. Past a few hundred million vectors with a sub-20 ms p99 budget, the warehouse implementations look thin. Distributed index sharding, replica management, and global low-latency index operations are real engineering, and the dedicated vendors have a multi-year head start.
• Complex pre/post-filter combinations. "Find me the 50 most similar items where category = X AND price < Y AND in_stock = TRUE" is harder than it sounds — filter selectivity changes which index strategy wins. Dedicated vector DBs ship more thoughtful planners for this; warehouse implementations mostly cover the simple post-filter case so far.
• Multi-modal hybrid retrieval. Serious late-2025 RAG stacks combine dense vector + sparse BM25 + cross-encoder rerank in a single API call with score fusion. The warehouses don't have an integrated story for that yet; the dedicated vendors do.
• Multi-tenant isolation. If your vector workload serves an external API with hundreds of tenants and strict isolation requirements, a managed vector DB is more turnkey than rolling that on top of warehouse credentials.

None of these are going away. They're the working corpus of the dedicated vendors' next few years. The shift is just that the default path no longer leads to a separate database — it leads to whichever engine your data already lives in.

The architecture choice for late 2025

The honest decision framework: stay in the warehouse unless you have a specific reason to leave it.

• Embedding count < ~50M: Just use pgvector or DuckDB VSS. The index fits, the queries are fast enough, the ops surface is zero. Don't add a database.
• Embedding count 50M-500M, mixed analytical + search workload: Snowflake, BigQuery, or ClickHouse 25.8+ with the native vector index. You'll trade some recall-at-tail for not running a second system.
• Embedding count > 500M, dedicated low-latency search service: A dedicated vector DB is probably still the right answer. Pinecone, Qdrant, Weaviate, Milvus — pick on operational fit and your team's existing skills.
• Hybrid retrieval, reranking, complex query DAGs: Dedicated vector DB or a purpose-built RAG service. The warehouse path doesn't have parity yet.
• You don't know yet and you're prototyping: pgvector. Always. If you outgrow it, you'll know exactly which axis you outgrew, which makes the next choice easy.

The interesting structural shift is that this is now a question with a default answer. Two years ago, "do I add a vector database to my stack" was a meaningful architectural debate. In late 2025 it's mostly a configuration line: CREATE INDEX ... USING HNSW (embedding vector_cosine_ops); on whatever engine you already run. The warehouses didn't reinvent vector search. They just absorbed it, the way analytical engines absorb every workload that turns out to be a column scan in disguise.