Vector databases are the wrong abstraction
timescale.com
Vector databases are the wrong abstraction
1–10 of 95 posts
Re: Vector databases are the wrong abstraction
#2Hey 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 reactions. If you'd like to leave an issue or better yet a PR, you can do so here [1]
Re: Vector databases are the wrong abstraction
#3[deleted]
Re: Vector databases are the wrong abstraction
#4Wow, actually a good point I haven't seen anyone make.
Taking raw embeddings and then storing them into vector databases, would be like if you took raw n-grams of your text and put them into a database for search.
Storing documents makes much more sense.
Re: Vector databases are the wrong abstraction
#5Wow, actually a good point I haven't seen anyone make. Taking raw embeddings and then storing them into vector databases, would be like if you took raw n-grams of your text and put them into a database for search. Storing documents makes much more sense.
Been using pgvector for a while, and to me it was kind of obvious that the source document and the embeddings are fundamentally linked so we always stored them "together". Basically anyone doing embeddings at scale is doing something similar to what Pgai Vectorizer is doing and is certainly a nice abstraction.
Re: Vector databases are the wrong abstraction
#6Great point!
(Disclaimer: I work for Elastic)
Elasticsearch has recently added a data type called semantic_text, which automatically chunks text, calculates embeddings, and stores the chunks with sensible defaults.
Queries are similarly simplified, where vectors are calculated and compared internally, which makes a lot less I/O and a lot simpler client code.
https://www.elastic.co/search-labs/blog/semantic-search-simp...
Re: Vector databases are the wrong abstraction
#7I’m using sqlite-vec along with FTS5 in (you guessed it) SQLite and it’s pretty cool. :)
Re: Vector databases are the wrong abstraction
#8This reads solely as a sales pitch, which quickly cuts to the "we're selling this product so you don't have to think about it."
...when you actually do want to think about it (in 2024).
Right now, we're collectively still figuring out:
1. Best chunking strategies for documents
2. Best ways to add context around chunks of documents
3. How to mix and match similarity search with hybrid search
4. Best way to version and update your embeddingsRe: Vector databases are the wrong abstraction
#9Whats wrong with using FAISS as your single db?
Its like sqlite for vector embeddings, and you can store metadata (the primary data, foreign keys, etc) along with the vectors, preserving the relationship.
Not sure if the metadata is indexxed but at least iirc it's more or less trivial to update the embeddings when your data changes (tho i haven't used it in a while so not sure).
Re: Vector databases are the wrong abstraction
#10Great point! (Disclaimer: I work for Elastic) Elasticsearch has recently added a data type called semantic_text, which automatically chunks text, calculates embeddings, and stores the chunks with sensible defaults. Queries are similarly simplified, where vectors are calculated and compared internally, which makes a lot less I/O and a lot simpler client code. https://www.elastic.co/search-labs/blog/semantic-search-sim…
How does their embedding model compare in terms of retrieval accuracy to, say `text-embedding-3-small` and `text-embedding-3-large`?