turbopuffer demotes the vector index in v3, reigniting the Postgres vs vector DB debate

turbopuffer is demoting the vector index

turbopuffer, the search layer behind Cursor and Notion, used a September 30 blog post titled "RIP, vector database" to announce a structural overhaul of its engine. In version 3, documents will be keyed by a stable document ID, and the approximate nearest neighbour index becomes a secondary index rather than the primary data structure. Vector search keeps working; it simply stops being the organising principle of the storage layer.

The company has the workload to back the argument. According to a dev.to analysis by jamilxt, Cursor runs billions of vectors across millions of codebases on turbopuffer, while Notion serves more than 10 billion vectors over millions of namespaces. turbopuffer claims single indexes of 100 billion-plus vectors, 200 ms p99 reads and more than 1,000 queries per second.

The reason is write amplification

turbopuffer's current layout stores a document's full contents keyed by its vector's cluster address. When the clustering index rebalances — which happens on routine inserts and updates — the entire document and every inverted index entry pointing at it move too. turbopuffer says a single vector update can drag hundreds of attributes along with it. The dev.to piece adds that query plans were locked to cluster-sized blocks of 100–200 documents, compared with 2,048-row batches in DuckDB and up to roughly 65,000 rows in ClickHouse.

Two caveats temper the announcement. turbopuffer admits v3 is currently a significant performance regression that is only starting to be tuned, even though it reports all CI passes green as of early October. And the economics are unchanged: object storage remains the source of truth, with the original pitch of about $70 per TB per month with an SSD cache versus roughly $1,600 for cache-plus-SSD incumbents, per the figures cited on dev.to.

The Postgres question the article raises

The dev.to piece, which draws on turbopuffer's blog posts and a Hacker News thread, argues the announcement should push teams to re-ask a question they often skipped: was Postgres fine all along? The author describes a recurring pattern — a team reads a benchmark, concludes Postgres cannot serve its embeddings, migrates to a dedicated vector database, and ends up with a second database, a sync job, a new failure mode and a speedup no user notices.

On raw numbers, Supabase benchmarked pgvector at roughly 1,800 QPS with 0.91 accuracy@10 on a one-million-vector dataset using a 16-core, 256 GB server. The dedicated-engine counterpoint is that beyond roughly 100 million vectors, purpose-built engines win on latency and memory: HNSW graphs are memory-hungry and Postgres has no built-in sharding for vector workloads. turbopuffer's own data highlights storage economics instead — one million 768-dimension vectors fit in about 3 GB, cold queries land around 444 ms p90 from object storage and warm ones around 10 ms p90, so tiering beats holding everything in RAM at a fraction of the cost.

Query shape often decides it

The strongest Postgres case, per the dev.to article, is the shape of real queries: similarity search combined with tenant filters, joins, permissions and ranking. In Postgres that is one SQL statement inside one transaction; in a dedicated vector engine, the join back to relational data typically happens in application code as a second round trip. Partial HNSW indexes scoped to a high-traffic workspace keep the graph small and recall high, and pgvector documents iterative index scans with exact fallback for selective filters. Re-embedding a changed document and deleting stale vectors can also happen in the same transaction as the content update — trivial in one database, a distributed consistency problem across two.

Where a dedicated engine still wins

The article concedes three cases: multi-tenant workloads at Notion scale, where object-storage tiering is effectively the business model; very large single indexes past the 100-million-vector mark, where the HNSW graph demands more RAM than the data itself; and late-interaction, multi-vector retrieval such as ColBERT, which stores dozens of vectors per document — exactly the amplification problem turbopuffer v3 exists to fix, and a poor fit for row-based Postgres storage too. The author's closing observation is that these are scale problems, and teams debating them before launch are debating the wrong thing.

Why it matters

The most successful vector-search company of this cycle has concluded that treating vectors as special made everything else worse. That weakens the reflex of adding a dedicated vector database the moment embeddings appear, and it reframes what the high end of the market is actually selling: storage economics and tiering at billions of vectors, not the index itself. For most teams the practical takeaway is to start in Postgres, design around the query shapes you actually run, and let measured scale — not benchmark posts — force any migration.