RIP, vector database
Vector databases are increasingly seen as the wrong abstraction for most real-world retrieval tasks, with many engineers favoring traditional SQL or search engines that treat vector search as just one index alongside text, metadata filters, and joins. Commenters highlight how using vectors as a primary storage layout leads to severe write amplification and complexity, drawing parallels to historical indexing trade-offs in Postgres and MySQL and endorsing designs where approximate nearest neighbor (ANN) indexes point to stable document IDs instead. The consensus trend is toward “multi-modal” data systems—ClickHouse, Postgres extensions, Elasticsearch, Vespa, LanceDB, and others—that integrate vector search into existing database capabilities rather than relying on standalone vector stores.
Page loading and performance
- Some users initially couldn’t load the blog page; others reported it loading quickly once server load issues subsided.
- Performance measurements varied: some saw sluggish behavior and middling Pagespeed scores, others reported excellent Lighthouse metrics and near‑instant rendering.
- There’s disagreement over whether the slowness is on the client side vs. server load; several note that bandwidth (e.g., 10G vs 1G) is not the bottleneck.
SQL/analytics databases vs. dedicated vector databases
- Multiple commenters argue that for enterprise retrieval, vectors are “just another” column and index type inside an existing SQL or search system.
- Advantages cited for SQL + vectors: easier joins, filters, ACLs, multi‑tenant isolation, metadata constraints, temporal filters, and avoiding the complexity of syncing a separate vector store.
- Examples mentioned include databases and engines that now support native vectors or combined vector + full‑text search.
Index design and parallels to Postgres/MySQL
- A major theme: using an ANN address as a primary key leads to heavy write amplification when vectors move.
- Commenters draw direct analogies to historical Postgres vs. MySQL index design trade‑offs (secondary indexes pointing to row locations vs. primary keys).
- Consensus: it’s often better for the ANN index to point to a stable document ID and accept an extra lookup, even if that means an additional hop (possibly to object storage).
“RIP vector database” interpretation
- Several people stress that what’s being “killed” is a vector‑primary storage layout, not vector search itself.
- They note this effectively makes ANN a secondary index, aligning vector databases with general search engines that already mix dense, sparse, lexical, and filtered queries.
- Some see the title as mostly marketing; the underlying point is architectural.
Custom and embedded search systems
- Some practitioners report better results by building bespoke or embedded systems (e.g., SQLite with custom IVF indexes, GPU‑accelerated index building), especially for local or single‑user tools.
- Others caution against reinventing databases for every use case, emphasizing the value of mature formats like SQLite/parquet and existing tooling.
LLM-written comments and moderation concerns
- There is visible anxiety about LLM‑generated comments on HN, accusations of “shills,” and worries about astroturfing and opinion manipulation.
- Gated registration (as on invite‑only forums) is discussed as a partial mitigation, but its long‑term effectiveness is debated.
- Some see frequent accusations of “this looks like AI” as a new form of low‑effort dismissal rather than substantive critique.
AI hype, tone, and skepticism
- A few commenters dismiss the post as “AI slop” or over‑hyped, critiquing the marketing tone and title.
- Others defend the technical depth and insist the article was hand‑written, noting that stylistic tics now attributed to LLMs long predate them.
- More broadly, commenters observe the volatility of AI hype cycles and express a preference for established SQL systems as the dust settles.