Live data from Hacker News

Vector databases are the wrong abstraction

timescale.com

61–70 of 95 posts

Re: Vector databases are the wrong abstraction

#61
post #58

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 ..?

Is SAP HANA used for anything outside the SAP environment?

Re: Vector databases are the wrong abstraction

#62
Or 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

#63

Or 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

BM25 implemented in Postgres as a Postgres extension: https://github.com/paradedb/paradedb (disclaimer: I work for ParadeDB)

Re: Vector databases are the wrong abstraction

#64
We managed 200M long and short form embeddings (patents), indexed in scann at runtime and a metadata layer on leveldb. Some simple murmur hash sharding and a stable K8s cluster on GCP was all we needed. Low millisecond retrieval and rerank augmenting a primary search.

I 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

#65

Or 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

Yeah when I implemented a RAG myself I wondered why people were storing the text separately, it doesn't make any sense to me!

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

#66
post #2

Hey 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?

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

#67

Or 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

[deleted]

Re: Vector databases are the wrong abstraction

#68

Earlier 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?

[deleted]

Re: Vector databases are the wrong abstraction

#69
I 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 :)

Re: Vector databases are the wrong abstraction

#70

I 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 consider it an upside

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?

Post reply on HN