I agree that putting the vectors in a separate DB often does not makes. Just use Hana https://news.sap.com/2024/04/sap-hana-cloud-vector-engine-ai... ;-) IMHO putting the calculation of the embedding vectors into the db (even if it is just a remote call) is not a got idea. How do you react to failures of the remote call, security issues because of code running within your DB ..?
Vector databases are the wrong abstraction
61–70 of 95 posts
Re: Vector databases are the wrong abstraction
#62Shameless plug:
BM25 search implemented in PL/pgSQL: https://github.com/jankovicsandras/plpgsql_bm25
faster BM25 search algorithms in Python: https://github.com/jankovicsandras/bm25opt
Re: Vector databases are the wrong abstraction
#63Or you can use Postgres to store the original text, the metadata and the embedding in a single table and then do hybrid queries against them (with pre- or post-filtering, optimized automatically). Shameless plug: BM25 search implemented in PL/pgSQL: https://github.com/jankovicsandras/plpgsql_bm25 faster BM25 search algorithms in Python: https://github.com/jankovicsandras/bm25opt
Re: Vector databases are the wrong abstraction
#64I think in 0 cases would we go back and use vector dbs or managed services if they were available to us (to include lucene or relational db add-ons)
Re: Vector databases are the wrong abstraction
#65Or you can use Postgres to store the original text, the metadata and the embedding in a single table and then do hybrid queries against them (with pre- or post-filtering, optimized automatically). Shameless plug: BM25 search implemented in PL/pgSQL: https://github.com/jankovicsandras/plpgsql_bm25 faster BM25 search algorithms in Python: https://github.com/jankovicsandras/bm25opt
It's not that "vector databases are the wrong abstraction", it's that "vector data is not an abstraction at all". It's just a data type with some operators, you are responsible for architecting that tool into your system in a coherent way.
Re: Vector databases are the wrong abstraction
#66Hey HN! Post co-author here, excited to share our new open-source PostgreSQL tool that re-imagines vector embeddings as database indexes. It's not literally an index but it functions like one to update embeddings as source data gets added, deleted or changed. Right now the system only supports OpenAI as an embedding provider, but we plan to extend with local and OSS model support soon. Eager to hear your feedback and…
Thank you for sharing this! I have one question: Is there any plan to add support for local LLM / embeddings models?
I mean why is that even a question? Is there some fundamental difference between the black box that is GPT-* and say, LLaMA, that I don't grok?
Re: Vector databases are the wrong abstraction
#67Or you can use Postgres to store the original text, the metadata and the embedding in a single table and then do hybrid queries against them (with pre- or post-filtering, optimized automatically). Shameless plug: BM25 search implemented in PL/pgSQL: https://github.com/jankovicsandras/plpgsql_bm25 faster BM25 search algorithms in Python: https://github.com/jankovicsandras/bm25opt
Re: Vector databases are the wrong abstraction
#68Earlier quoted context omitted.
Thank you for sharing this! I have one question: Is there any plan to add support for local LLM / embeddings models?
This question keeps popping up but I don't get it. Everyone and their dog has an OpenAI-compatible API. Why not just serve a local LLM and put api.openai.com 127.0.0.1 in your hosts file? I mean why is that even a question? Is there some fundamental difference between the black box that is GPT-* and say, LLaMA, that I don't grok?
Re: Vector databases are the wrong abstraction
#69Personally, I can vouch for ParadeDB: https://www.paradedb.com/
It adds extra extensions to PostgreSQL which enable vector indexing, full text search and BM25. Works great and developers are helpful!
The major difference is that you must generate the embeddings by yourself, but I consider it an upside - to each their own :)
Re: Vector databases are the wrong abstraction
#70I agree with the author - introducing a vector database often isn't worth the extra complexity. Personally, I can vouch for ParadeDB: https://www.paradedb.com/ It adds extra extensions to PostgreSQL which enable vector indexing, full text search and BM25. Works great and developers are helpful! The major difference is that you must generate the embeddings by yourself, but I consider it an upside - to each their own :…
I'm curious why you consider an upside. Hypothetically speaking, wouldn't it be better if the embeddings could automatically be updated when you want them to be? Is the problem that it's not easy to automated based on the specific rules of when you want updates to happen?