Every database will become a vector database sooner or later

Absolutely this is par for the course for distributed engines.. just not postgres and other single node engines which a lot of people here will tell you are all you need.. what they mean is that's all you need until you either have to introduce enormously complex application tier sharding or you're moving to a scalable engine

It stores everything on cheap storage, with no compute associated (i.e. S3) and uses the client to compute the query embeddings and to retrieve the embedding index and to run an indexed search to identify the data to be retrieved, and likewise the client does the work of updating the index structure on writing.

The benefit is that you don't have to pay for the compute part of a database, and the storage layer is as cheap as it could be on the cloud.

the interest in vector database rise as an external, specialized service in a system that runs in addition to the "single source of truth" data lake where the data actually resides. like Redis and Memcached before, it solves a specific problem. Redis started to act like a fully fledged DB (with weird persistency method and guarantees) only after it was really wide-spread. sure, every DB will support vector and every vector search engine will act like a DB. But that's missing the point that vector search is an expensive problem with tradoffs that justify a specialized design

btw I'm working in a DB startup - https://hyper-space.io/

We recently added vector support to FeatureBase: https://cloud.featurebase.com/. What's interesting about using it with our existing b-tree storage layer is that I can now do set operations on the record's stringset fields before I do the similarity calculations on the vectors. I've been experimenting with laying out the vector space in a b-tree structure using this technique along with keyterm extraction, allowing for a type of semantic graph to be applied by the LLM to the vector space.

Go ahead and try to load a billion embeddings into Mongo or Elastic. The author says this will be "faster, cheaper, and simpler..." Will it?

(Disclaimer: I work for Pinecone, so obvious bias ahead but also perspective of 3 years since launching the Vector DB category and actually seeing billion-scale vector search deployments.)

> Basically, having separate vector DBs can add to cost and complexity. Imagine you were a MongoDB shop, with over 500m documents stored cross-region. If you are using a separate vector DB, say Pinecone, that may require moving potentially billions of embeddings between two databases, cross regions. This costs a lot, not to mention complex, since you are responsible for generating the embeddings... It’s faster, cheaper, and simpler if one database (Mongo, Elastic) just supported vector search.

If you want, say, 100ms search latency on just 100M vector embeddings in Elastic that'll already cost you $12,600 per month at minimum. And if you regularly write new or updated data to the index then your latencies will creep up until eventually you have to run a "force merge" which will grind your vector search to a halt for several hours (so much for easy and simple). I don't know how much it is on Mongo but given that it's bolting on the same vector index I would guess it's in the same ballpark. The cost grows sublinearly with more embeddings. (Pinecone is around 60% less than that, and will be even less soon.) The suggestion that having "billions" of embeddings in a traditional DB is easier and less costly shows you exactly why you should run your own tests and see for yourself.

When traditional database companies bolt-on vector indexing libraries such as HNSW[0] on top of their existing architecture, it's to meet demand from their existing users that have a relatively basic need for vector search.

For very basic and small-scale use cases, like When it comes to larger scale, like 100M+ vectors, if you want any hope of meeting performance, cost, and data freshness requirements then you should look at a purpose-built vector database. As GenAI workloads start to enter production and scale, a lot of people will see find this out the hard way.

This has been true for every unique data structure and querying pattern for the past 40 years and it’s true for vector embeddings and vector-based retrieval. You can't blame the proliferation of different database types on hype and VC funding alone.

But don't take my word for it either. Go and run some tests that resemble your production workloads, then do what makes sense for your use case!

[0] https://www.pinecone.io/learn/series/faiss/hnsw/