Vector Databases Are Dead. SQL Won. Stop Betting on the Wrong Layer.

I am going to be direct. The dedicated vector database as a standalone product category is finished. Pinecone, Weaviate, Qdrant, Chroma, Milvus — they are the next generation of MongoDB-in-2014: a hot infrastructure bet that was outflanked by the relational engine underneath it before the company could finish its Series C deck. SQL won. Specifically, Postgres won. Stop standing up a separate vector store in 2026.

The Query You Are Paying $30,000 a Month to Run

The canonical "vector database" query in 2026 is: find the top 50 nearest neighbors of an embedding, filter by tenant, return metadata, group by document, only show results newer than 30 days. In Postgres with pgvector, that is one statement:

sql SELECT id, content, metadata, 1 - (embedding <=> $1) AS score FROM documents WHERE tenant_id = $2 AND created_at > now() - interval '30 days' ORDER BY embedding <=> $1 LIMIT 50;

It runs on the Postgres you already operate. The HNSW index lives next to the row. The metadata lives in the same row. The tenant filter is a B-tree on the same heap. There is no second connection pool, no eventual consistency between source of truth and index, no second billing line, no second pager rotation, no second backup story. The dedicated vector database is doing nothing here that Postgres does not already do better, cheaper, and with stronger consistency guarantees.

The Performance Gap Closed

The last argument the dedicated players had was performance. "You cannot do billion-scale vector search on Postgres." That was true in 2022. It is not true in 2026. pgvector shipped HNSW in late 2023 and DiskANN integration followed. As of pgvector 0.8, the recall-vs-latency curve on standard ANN benchmarks sits within 2x of Qdrant's tuned configuration for the workloads 95% of teams actually run — sub-10M vectors, metadata filtering, recall above 0.95. The 2x gap closes to 1.2x if you tune your ef_search and m parameters, which a competent DBA does in an afternoon.

The billion-scale pure-vector workloads — TikTok, Pinterest, Spotify — were never the addressable market. They were the marketing. The real market was 1M-10M vectors with heavy metadata filtering, and that market just got served by an extension you install with CREATE EXTENSION vector;.

The Cloud Catch-Up

It is not only Postgres. SQLite has sqlite-vec. MySQL has vector support in 8.4. ClickHouse has vector search. DuckDB has vss. Snowflake, BigQuery, Azure Cosmos, Oracle — all have it. The hyperscalers all shipped vector search in the same eighteen-month window. They are not racing to add a feature to a dying category; they are racing to make sure the dedicated vector store is not a reason to leave their platform. The category is consolidating, not expanding.

Who Is Going to Lose

The teams building dedicated vector databases as a business. Pinecone is the loudest name and the most exposed. Weaviate and Qdrant will end up as open-source projects that one or two cloud vendors bundle. Milvus will be a Zilliz line item that never makes money. Chroma will be remembered as the thing LangChain users copy-pasted in 2024 and then deleted.

The teams that built their entire product on top of a dedicated vector store without a migration plan. If your architecture diagram has a dotted line between your Postgres and your Pinecone index, you have a future incident. The venture funds that wrote checks at $500M-plus valuations into a category whose TAM just collapsed into a Postgres extension — they knew. The deck said "we are the database for the AI era." The AI era picked Postgres.

The Take

I will die on this hill: by the end of 2027, the standalone vector database as a venture-scale product category will be functionally dead. Not bankrupt dead — Qdrant and Weaviate will limp along as open-source projects. Dead as in "no team starting a new AI application in 2027 will reach for a separate vector store as the default." pgvector is the default. sqlite-vec is the default for local. The query is a SQL query. The infrastructure is a SQL database. The standalone layer lost the way the document store layer lost to Postgres JSONB.

If you are evaluating Pinecone in the second half of 2026, you are evaluating the wrong category. If you are pitching a vector database startup, you are pitching into a TAM that already has an answer — and the answer is free, runs on infra you already pay for, and has a 25-year track record of not going down.

SQL won. It was always going to. The sooner the industry admits it, the sooner we stop paying a tax on a category that should not exist.

— Mr. Technology