Vector Database Consolidation: Who Is Left in 2026, and What Won

Three years ago, "vector database" was the most-pitched category at every AI conference. By a rough count from CB Insights, more than thirty venture-backed companies were competing for the same workload. The pitch decks were nearly identical: faster than Postgres, cheaper than Pinecone, more features than Weaviate.

By May 2026, that market has consolidated almost completely. Six players matter at production scale. Most of the rest were acquired, pivoted, or quietly ran out of runway. The story of which six survived — and which architecture choices ended up being load-bearing — is one of the cleaner natural experiments the AI infrastructure market has run.

The 2023 Field, Briefly

In 2023 the contenders included Pinecone, Weaviate, Qdrant, Milvus, Chroma, Vespa, Vald, Marqo, Vectara, Pinecone Serverless (separately positioned), Zilliz, LanceDB, Turbopuffer, MyScale, Couchbase Capella columnar, Redis Vector, Elasticsearch Vector, MongoDB Atlas Vector Search, OpenSearch Vector, Tigris, SingleStore, AlloyDB, Supabase pgvector, Neon pgvector, Cloudflare Vectorize, Pinecone Hybrid, Astra DB Vector, and a half-dozen specialized GPU-native options.

Most of these are still alive. Most of them are not winning new logos.

Who Is Actually Winning in 2026

The six that matter for serious workloads:

| Database | Best for | Approximate market position | |----------|----------|----------------------------| | pgvector (on Postgres) | Default for <50M vectors | Largest by deployment count | | Turbopuffer | Cost-sensitive, bursty | Fastest-growing | | Qdrant | Self-hosted, filter-heavy | Strongest in EU and gov | | LanceDB | Embedded, single-node | Standout for ML pipelines | | Pinecone | Managed, enterprise | Still the AWS of vector | | Weaviate | Hybrid search out-of-box | Steady, niche-defensive |

Notable absences: Chroma, Milvus, and Vespa are still in use but rarely chosen for new builds. Redis Vector, MongoDB Atlas Vector, and Elasticsearch Vector all retain user bases but lost the "primary vector store" position.

Why Postgres Won the Default

The single most important development between 2023 and 2026 was that pgvector got dramatically better. The 0.5 release added HNSW indexing, the 0.7 release added quantization, and the 0.8 release in late 2025 closed most of the remaining performance gap with dedicated vector DBs at moderate scale.

Combined with managed Postgres providers — Neon, Supabase, AlloyDB — running pgvector became operationally trivial. The result: most teams now start with the database they already have. The default migrated from "spin up a vector DB" to "enable an extension."

This shift killed the value proposition of about a third of the original contenders. If your only differentiation was "we are a vector database," and Postgres can do it, you needed a second differentiator. Most did not have one.

Why Turbopuffer Came Out of Nowhere

Turbopuffer launched in 2023 with a strange architectural bet: store vectors on S3, lazily load index pages into memory, charge only for query compute and storage. Almost everyone in the market thought it would be too slow.

It turned out that for the actual shape of production RAG workloads — long-tail queries, mostly cold vectors, aggressive caching at the application layer — the architecture was nearly optimal. Customers reported 10-100x cost savings versus traditional vector DBs at comparable latencies for non-hot-path queries.

Notion's switch from a custom Pinecone setup to Turbopuffer in early 2025, reportedly cutting their retrieval bill by 90%, was the case study that moved the rest of the market. By May 2026 most new RAG-heavy startups evaluate Turbopuffer first.

Why Qdrant Held the Self-Hosted Segment

Qdrant did not chase the managed-cloud market hard. It instead built the cleanest self-hosted experience and the strongest filter-and-payload story. For European customers, government workloads, and enterprises with data-residency requirements, that combination was decisive. Qdrant Cloud exists and is fine; the deeper moat is that the OSS version is genuinely production-grade.

Why LanceDB Found a Niche

LanceDB took the embedded-database route — install as a library, store data in a single columnar format, run inside the application process. For data scientists building offline ML pipelines and for products that ship vector search inside an installed application (think desktop apps, edge devices), this is the only sensible architecture. There is no manageable competitor in that shape.

What Happened to the Rest

A non-exhaustive postmortem:

• Chroma: still beloved by prototypers, lost the production segment to pgvector. The team is now building something different.
• Milvus: still technically excellent, lost mindshare on operational complexity.
• Vespa: still the best at very large scale, but the "very large scale" segment is small.
• Marqo: pivoted toward retrieval-as-a-service, niche but defensible.
• Vectara: pivoted to a full RAG platform, more enterprise sales motion.
• Zilliz: managed Milvus, steady but flat.
• MyScale: positioned on SQL + vector, never broke out.

The acquisitions that mattered: Snowflake acquired a smaller vector startup for column-vector integration; Databricks similarly. Neither announced a major standalone product.

Is RAG Dead? (No, But It Changed Shape)

The thread "RAG is dead" trended on X repeatedly through 2025. The substance of the argument: long-context models can fit entire documents directly, so retrieval is unnecessary. The reality is more nuanced.

Naive RAG — embed everything, top-k, stuff into context — is past peak. Production retrieval in 2026 looks like:

1. Hybrid search: vector + BM25, fused with reciprocal rank fusion
2. Reranking: a smaller cross-encoder model on the top-50 results
3. Agentic retrieval: an agent that runs multiple targeted searches rather than one big one
4. Long-context fallback: when retrieval is uncertain, dump more context and let the model decide

The vector database is one component of this stack, not the whole thing. The teams that won are the ones who stopped pretending vector search alone was enough.

What This Means for Builders

If you are picking a vector database in May 2026:

1. Default to pgvector if you already run Postgres
2. Evaluate Turbopuffer if cost or scale is a concern
3. Use Qdrant for self-hosted or filter-heavy workloads
4. Use LanceDB if you ship embedded software
5. Use Pinecone if you want managed simplicity at any cost
6. Consider Weaviate if you need hybrid search without integration work

That is the entire decision tree. It used to take a 90-minute meeting. It now takes ten.

The Takeaway

Vector databases were the most overfunded category in AI infrastructure in 2023 and one of the cleaner consolidation stories of 2025-2026. The survivors won by being either cheaper-by-architecture (Turbopuffer), better-integrated (pgvector), or operationally cleaner (Qdrant, LanceDB). Pure-play vector databases without an additional moat got squeezed from both ends. The category is healthier for the consolidation, and builders are better off — picking a vector DB is finally easy.

A Closer Look at the Architectural Bets

The interesting part of this consolidation is not which companies survived. It is which architectural bets paid off. Three patterns are worth pulling out.

The Storage-Compute Separation Bet

Turbopuffer's bet that S3 plus a smart caching layer could replace dedicated SSD storage was contrarian in 2023. The pushback was that S3 latency would be too high for serving query traffic. The counterargument was that production retrieval workloads have a long tail of cold queries and a small hot working set, and that this shape happened to be perfect for cache-on-demand.

The numbers in 2026 confirmed the counterargument decisively. Most production RAG workloads have a query distribution where the top one percent of vectors handle thirty percent of the queries, and the bottom seventy percent handle under two percent. Storing the cold majority on S3 is essentially free; serving it from cache when it heats up is fast enough. The architecture that should not have worked won.

The Postgres-Is-Enough Bet

The pgvector contributors made an unfashionable bet that the right vector database for most teams was the database they already had. Through 2023 this was widely dismissed as naive. By 2026 it is the dominant deployment.

The technical work behind the win is underappreciated. HNSW indexing in 0.5, half-precision storage in 0.6, IVFFlat improvements in 0.7, quantization in 0.8 — none of these are individually exciting. Together they closed roughly 95% of the performance gap with dedicated vector DBs at moderate scale, while keeping the operational simplicity of "it is the same Postgres you were already running."

The Bet Against Standalone Vector DBs

The bet that lost was the assumption that "vector database" was a durable category on its own. It was a feature, not a product. Once Postgres got the feature, the category compressed. The dedicated vector DBs that survived did so by adding a second moat — Turbopuffer's storage architecture, Qdrant's self-hosted polish, LanceDB's embedded shape. The ones that did not, did not.

Migration Patterns for Existing Workloads

For teams running a vector DB in 2026 and considering a move, the realistic migration patterns:

Pinecone to Turbopuffer

The most common migration in late 2025 and early 2026. Cost-driven, usually triggered by a Pinecone bill above $5,000 per month. The mechanics are straightforward: export vectors, reindex on Turbopuffer, validate retrieval quality on a frozen evaluation set, cut traffic over with a feature flag.

The footgun is metadata filtering. Pinecone's filter language and Turbopuffer's are not identical, and silent retrieval-quality regressions are common when filter expressions do not translate cleanly. Build a test that exercises filtered queries before cutting over.

Anything to pgvector

Possible if your scale is below roughly fifty million vectors and your latency tolerance is roughly one hundred milliseconds. Above that, pgvector becomes operationally awkward without significant tuning. The migration itself is mechanically simple and the operational savings are real.

Self-Hosted to Managed

Less common in 2026 than the reverse. Most teams that started on Pinecone stayed on Pinecone or moved to Turbopuffer; few migrated from self-hosted Qdrant to a managed offering. The pull of operational ownership turned out to be stronger than expected once the self-hosted experience matured.

Related Reading

• choosing your first AI infra stack — Where vector DBs sit in the broader stack.
• DuckDB's internal design — Useful context on columnar query architecture.
• do you even need a database — The contrarian case for keeping it simple.