9 ms·

The argument that combining traditional database and vector database into one because it reduces data movement doesn't compute for me. Firstly, even for non ve

The argument that combining traditional database and vector database into one because it reduces data movement doesn't compute for me. Firstly, even for non vector data, read/write transactional database vs read-optimized store purely for fast serving are already markedly different. Then, the shape of data that is used to generate embeddings is markedly different than the shape of data that is ready to transact or serve. So, no matter where it is stored, it has to leave that store, get transformed and enriched and then run through an embeddings generator (ML inference). Then, it has to be stored in a manner that is optimal for retrieval ranking. If you are doing ANN that's one thing, but if you are doing attribute based filtering while retrieving and you wish to accelerate it through GPU to do more exhaustive search, that's another thing altogether. All these lead to fairly sophisticated optimized implementation. Sure, a singular database product solution that has all these different optimized engines can emerge over time but surely it is too early today to converge like this.

cheeseblubber 3y ago
The problem is maintenance of a separate database and operationally it would be more work. For us who want to use embedding features having a separate database just for the embedding means now we have to keep data across multiple databases in sync and to maintain
m00x 3y ago
> So, no matter where it is stored, it has to leave that store, get transformed and enriched and then run through an embeddings generator (ML inference). Same for pretty much all the data in your database. It comes from an app, that does validation/editing/transforms. The benefit is that it's all together, can be atomic, only requires one query to get, update, and delete. Vector databases are just normal databases with a vector index. There's no reason for you to have a specialized DB for it. Also, embeddings aren't inference, it's a token lookup. There's no forward pass.

cheeseblubber 3y ago

The problem is maintenance of a separate database and operationally it would be more work. For us who want to use embedding features having a separate database just for the embedding means now we have to keep data across multiple databases in sync and to maintain

m00x 3y ago

> So, no matter where it is stored, it has to leave that store, get transformed and enriched and then run through an embeddings generator (ML inference). Same for pretty much all the data in your database. It comes from an app, that does validation/editing/transforms. The benefit is that it's all together, can be atomic, only requires one query to get, update, and delete. Vector databases are just normal databases with a vector index. There's no reason for you to have a specialized DB for it. Also, embeddings aren't inference, it's a token lookup. There's no forward pass.