By ByteBot
Turbopuffer—a company with roughly $100M ARR built on selling vector database infrastructure—published a post this week titled “RIP, vector database.” This is not a competitor’s critique or an analyst take. The vendor itself is announcing it is redesigning its own storage architecture to stop treating vector search as the foundational organizing structure. If you added Pinecone to a RAG pipeline in 2023 because everyone said that’s how LLM retrieval works, now is a good time to reconsider that decision.
A Vendor Confessing Its Own Architecture Is Wrong
Additionally, the current design at turbopuffer—and at most dedicated vector databases—organizes all stored data around approximate nearest neighbor (ANN) cluster boundaries. Every document, every metadata field, every index lives inside clusters of 100-200 documents grouped by vector proximity. The problem: that works for pure vector queries but breaks everything else. Full-text search, aggregations, and metadata filtering must all be constrained to cluster boundaries that were never designed for them.
However, turbopuffer’s post names three structural flaws. First, storage amplification: multi-vector document representations—used in modern models like ColPali and late-interaction approaches—require duplicating all non-vector data for each vector. Second, write amplification: when a document updates, the rebalancing cascade moves the full document contents plus every inverted index that references it. Third, CPU inefficiency: query engines like DuckDB and ClickHouse batch 2,048 to 65,000 documents at a time for SIMD efficiency, but the ANN cluster cap of 200 documents makes that impossible. Their fix in v2 full-text search—switching to 256-document blocks instead of cluster-boundary constraints—already yields “10x smaller indexes” and “up to 20x faster” queries. The v3 redesign promotes ANN to a secondary index entirely.
In fact, to be clear about what is notable here: turbopuffer is not describing a competitor’s mistakes. It is describing the architecture it sold to customers and charged for. That candor is unusual, and it signals the vector-primary design has hit genuine scaling limits.
pgvector Is Already Good Enough for Most Teams
Consequently, while the vector database vendors were iterating on their architectures, PostgreSQL’s pgvector extension got quietly competitive. An April 2026 benchmark measuring pgvector with pgvectorscale found 471 queries per second at 50 million 1,536-dimensional vectors with 99% recall. Qdrant, one of the best-performing purpose-built vector databases, hit 41 QPS on the same hardware. pgvector wins on throughput by roughly 11x at that scale. Qdrant wins on P95 latency—37ms versus 60ms. For most RAG workloads where you run batch retrieval and throughput matters more than tail latency, pgvector is already the better choice.
In fact, the practical implication is short. If you are already on PostgreSQL and have fewer than 50 million vectors, you can run semantic search alongside your existing relational queries in a single statement:
-- Semantic search with metadata filter — no separate vector DB needed
SELECT id, content
FROM embeddings
WHERE created_at > '2026-01-01'
ORDER BY embedding '[0.1, 0.2, ...]'
LIMIT 10;Furthermore, one query. No separate database to operate. No synchronization lag between your application data and your vector index. No vendor lock-in. The “you need a dedicated vector database for RAG” advice from 2023 was, for most teams, marketing pressure dressed as architecture guidance.
The Market Is Delivering Its Verdict
Meanwhile, the commercial picture matches the technical argument. Pinecone—which raised $100M at a $750M valuation in April 2023—is reportedly exploring a sale after losing Notion as a customer. Elastic’s CEO, commenting on the situation, said that vector databases “were never a business.” Qdrant raised $50M in March 2026 just to stay competitive. Meanwhile, every major general-purpose database added native vector search: PostgreSQL, DuckDB, SQLite, Elasticsearch, ClickHouse, CrateDB. When six major platforms treat vector search as a default feature rather than a differentiator, the standalone category contracts.
Moreover, the Hacker News thread on turbopuffer’s post captures the practitioner consensus forming in real time: vector similarity is one query primitive among many, not an organizing principle for an entire database. The top comments draw parallels to MySQL versus PostgreSQL indexing strategies and point to pgvector and LanceDB as the practical answers most teams should have reached earlier.
Related: MongoDB CEO CJ Desai Quits for Meta — Stock Drops 25%
What to Actually Do With Your Retrieval Stack
Therefore, the decision tree is short. Under 50 million vectors and already on PostgreSQL: add pgvector, stop. Need embedded operation with no server—serverless functions, edge deployments, local-first apps: use LanceDB, which runs in-process like SQLite and handles larger-than-memory datasets via its columnar format. Need hybrid search at scale above 50M vectors with strict latency requirements: evaluate Qdrant now, watch turbopuffer v3 when it ships. Need to migrate away from a cloud-only vendor with no self-hosted option: Qdrant or LanceDB.
As a result, the advice to “just use Pinecone” made sense in early 2023 when pgvector was immature and everyone was moving fast. It does not hold in 2026. The fact that a $100M ARR vector database company just published “RIP, vector database” is the clearest possible signal that the architecture era is over.
Key Takeaways
- Turbopuffer published “RIP, vector database” this week—announcing their v3 redesign removes ANN as the primary index after identifying three structural flaws in the vector-primary architecture
- pgvector with pgvectorscale hits 471 QPS at 50M vectors, 11x more throughput than Qdrant—for most RAG workloads, it is the correct default
- Pinecone is reportedly exploring a sale; Elastic’s CEO called vector databases “never a business”; native vector search is now standard in PostgreSQL, DuckDB, SQLite, and Elasticsearch
- If you are under 50M vectors and on PostgreSQL, you almost certainly do not need a dedicated vector database
- For embedded or serverless use cases, LanceDB is the zero-overhead answer; for hybrid search at over 50M vectors with latency requirements, evaluate Qdrant
