Infrastructure October 2, 2026 neutral ⇧ 501 pts across 2 threads

Vector databases are folding into regular databases

"RIP, vector database" drew a clear response. One commenter said they see very little reason to use a pure vector database for enterprise retrieval, and that they built their retrieval engine on a SQL database with native vector support for the flexibility. Another compared the whole argument to Postgres versus InnoDB ten years ago, with an index design that rewrites every index touching a document on rebalance. Separately, a paper on Context Language Models got attention because it attacks the other half of retrieval, context management, and found that keeping invalid cache suffixes didn't hurt performance.

The through-line is that retrieval is being absorbed. The specialist store is losing to the general database with a vector column, and the context problem is being pushed into the model layer. Commenters on the CLM thread pointed out you can sort of fake this today by resending the file, at the cost of cache misses, so the benefit depends on how well it works in practice.

The nuance: the vector database post itself failed to load when first posted, which made at least one commenter groan about server load.


So what?

Don't add a dedicated vector database to your stack by default. Start in Postgres or whatever you already run, and move only when you can show a real limit. Also watch long-context and caching work, because it may shrink how much retrieval you need at all.

Read these