Agreed with your observations about the difference between the libraries and databases. Maybe for a follow-up article? It's nice to see some independent research on the topic, tho.
Yes! We carefully distinguish vector search vs vector databases throughout the article. The end sections on architectures touch on that, such as questioning compute-tier solution vs not.
Reality vs marketing seem to diverge here. On the compute side, Faiss and some others have scaling extensions (GPU, bigger-than-memory, ...) that both out-perform and out-scale some of the vector database solutions. Likewise, similar to redis, teams will use it in a rather persistent way in practice. Conversely, some vector db teams market traditional db notions like CRUD operations, but it is unclear how much that is their ideas talking, the need to meet VC funding stories, niche use cases, or what managed vector search users want. Likewise, if we did a comprehensive benchmark of vector databases vs say graph databases, I'm not sure which would win in many key cases, including on those vector databases advertise on.
Yes! We carefully distinguish vector search vs vector databases throughout the article. The end sections on architectures touch on that, such as questioning compute-tier solution vs not.
Reality vs marketing seem to diverge here. On the compute side, Faiss and some others have scaling extensions (GPU, bigger-than-memory, ...) that both out-perform and out-scale some of the vector database solutions. Likewise, similar to redis, teams will use it in a rather persistent way in practice. Conversely, some vector db teams market traditional db notions like CRUD operations, but it is unclear how much that is their ideas talking, the need to meet VC funding stories, niche use cases, or what managed vector search users want. Likewise, if we did a comprehensive benchmark of vector databases vs say graph databases, I'm not sure which would win in many key cases, including on those vector databases advertise on.
It's an interesting time!