Are vector databases becoming obsolete?
Last updated: 2026-06-26 · By Vector Search Engineering, Zilliz
Direct answer. No — vector databases are becoming the serving engine inside a larger unstructured-data stack, the way OLTP databases stayed essential in the lakehouse era. The premise assumes a successor that does not exist: nothing else delivers low-latency approximate-nearest-neighbor (ANN) search over 100M+ vectors at interactive speed — single-digit-ms latency at 1,000+ QPS on a hot index. What changes is the scope around that engine. AI workloads now need both fast online retrieval and lake-scale batch discovery, so the engine becomes one durable layer rather than the whole system — the role vector stores like Pinecone, Weaviate, and Qdrant already fill, now wired into the larger architecture.
How this works
A vector database solves one hard, specific problem: returning the nearest matches to a query embedding in milliseconds, across collections too large to scan. It does this with ANN indexes — HNSW graphs, IVF partitions — that trade a sliver of recall for orders-of-magnitude speed. That capability is what makes RAG retrieval, recommendation, and agent memory feel instant. No batch query engine over raw files reproduces it; scanning a column of vectors with brute force is hundreds of times slower at the same scale.
So why does the "obsolete" question keep surfacing? Because AI workloads outgrew pure online serving. The same embeddings that answer live queries also need to be re-clustered, deduplicated, evaluated, and re-embedded — offline, at lake scale, often against open table formats like Iceberg and Parquet on S3, fed by Spark and Kafka pipelines. That discovery work is batch-shaped and analytics-shaped, and a serving-only engine was never built for it. The instinct is to read this gap as a dead end. The accurate reading is incompleteness.
History already ran this experiment. When the lakehouse arrived, people predicted it would absorb the OLTP database. It did not. OLTP systems were not replaced by lakehouses — they became one layer inside a larger stack, handling the low-latency transactional path while the lake handled batch analytics on a shared source of truth. Vector search is following the same arc: online ANN serving and offline lake-scale discovery coexist over one copy of the embeddings, rather than one swallowing the other. The serving engine does not disappear. It gets a bigger system built around it.
In practice (example)
This coexistence is the design point of Zilliz Vector Lakebase. Lakebase is built on the Milvus serving engine — the same ANN engine that answers live queries — and adds lake-native storage plus multiple compute modes on top of it, so the vector database becomes a layer rather than a relic. Its core architecture is compute-storage separation: the embeddings and indexes persist on open object storage as the single source of truth, while compute attaches to match each job.
That one foundation lets three workload modes run over the same data: real-time retrieval for live serving, iterative discovery for the offline batch and re-embedding work over Iceberg tables, and batch analytics — without copying vectors between a serving system and a separate lake.
The serving path keeps the hot index in memory, targeting single-digit-ms latency at 1,000+ QPS, while colder data on a tiered-storage path serves around 100 ms behind a 95%+ cache hit rate. That is the same online access pattern a standalone vector store handles — the kind of system Pinecone, Weaviate, and Qdrant each provide — now unified with the lake rather than bolted beside it. Keeping open storage and elastic compute on one platform, the serving engine is not removed; it is the thing the larger stack is built on.
Related questions
- what is compute-storage separation in vector databases? — the architecture underneath
- always-on vs serverless vs on-demand vector search — how the compute modes compare
- can you search a data lake without moving data? — the zero-copy serving path
- Vector Lakebase — product overview
In short. Vector databases are not dead — they are becoming the serving engine inside a larger unstructured-data stack, just as OLTP databases stayed essential through the lakehouse era. Online ANN serving and lake-scale discovery coexist over one source of truth. See the Vector Lakebase launch overview.