RIP, vector database
- ID
- 30939
- Status
- summarized
- Published
- 02 Oct 2026, 12:01 AM
- Fetched
- 02 Oct 2026, 4:44 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://turbopuffer.com/blog/rip-vector-database
- Source URL
- https://hnrss.org/best
Summary
- Score
- 6.0
- Created
- 02 Oct 2026, 4:44 AM
- Tags
- Audience
- developersdatabase_learnersai_ml_learnerssaas_founders
What happened
turbopuffer published the first post in a series on its upcoming v3 storage architecture, saying it is moving off a vector-primary design in which the ANN index is the primary index all other indexes and query plans revolve around, and making ANN 'just another' secondary index. The recap covers v1 (documents were only an ID and a vector, object storage as source of truth plus tiered NVMe SSD/memory caches, with Cursor and Notion named as early customers) and v2 (strong text and regex search, used by Linear for a syncing engine), and states the vector-primary layout has constrained query plans like GROUP BY and aggregations. No migration timeline, benchmarks, or pricing appear in this first update; the post is framed as setting the stage for following along.
Why it matters
If you are choosing or already running a dedicated vector store, this is a concrete argument that a vector-first index can block SQL-style query plans (GROUP BY, aggregations) and hybrid text/regex work — so if your roadmap includes analytics or filtered aggregations over the same data as your embeddings, weigh that against a general query engine or Postgres+pgvector. Do not schedule anything from this post: it names no release date, no performance numbers, and no migration path, so the 'RIP, vector database' framing is positioning until v3 ships with measured results. Nothing in the text ties this to Malaysian or SEA infrastructure, pricing, or policy, so there is no local angle to act on yet.
Discussion angle
Which of your own queries are actually blocked by a vector-first index — GROUP BY, aggregations, or heavy filtering alongside ANN search — and would that push you to a general query engine rather than a dedicated vector DB? Worth reading the 58-comment thread for where practitioners disagree with the 'vector database is dead' framing.