I still haven't figured what a vector DB is, beyond something something AI.
Every database will become a vector database sooner or later
101–110 of 143 posts
Re: Every database will become a vector database sooner or later
#102Go ahead and try to load a billion embeddings into Mongo or Elastic. The author says this will be "faster, cheaper, and simpler..." Will it? (Disclaimer: I work for Pinecone, so obvious bias ahead but also perspective of 3 years since launching the Vector DB category and actually seeing billion-scale vector search deployments.) > Basically, having separate vector DBs can add to cost and complexity. Imagine you were a…
Your argument is reasonable, however, you haven't explained why a purpose-built vector database is more scalable than any other DB with vector search support. Why is Elastic much slower than Pinecone? Is it because Pinecone is optimized in ways that Elastic cannot be? Is it because the Pinecone team has much better understanding on how to optimize vector search algorithms? or is it something else?
Re: Every database will become a vector database sooner or later
#103Earlier quoted context omitted.
It stores everything on cheap storage, with no compute associated (i.e. S3) and uses the client to compute the query embeddings and to retrieve the embedding index and to run an indexed search to identify the data to be retrieved, and likewise the client does the work of updating the index structure on writing. The benefit is that you don't have to pay for the compute part of a database, and the storage layer is as c…
At the expense of latency ? when in fact latency is the most important aspect for any search. Any idea on how fast the searches from the client are ? retrieve the embedding index and to run an indexed search to identify the data to be retrieved. Please bear with the layman like questioning - So if the data is {obj: "obj1, "data": {"name": "atlas", "embedding": "1123124234" } What is an embedding index ? Is it somethi…
Eh, sure latency is suboptimal. But if you have a LLM in the mix, that latency will dominate the overall response time. At that point you might not care about how performant your index is, and since performance/cost is non linear, it can translate to very significant savings
Re: Every database will become a vector database sooner or later
#104I still haven't figured what a vector DB is, beyond something something AI.
I was hoping the article would say and then when it didn't I was hoping the comments would, but so far no luck...
Re: Every database will become a vector database sooner or later
#105I still haven't figured what a vector DB is, beyond something something AI.
VectorDBs let you retrieve documents that have textual similarity.
They allow you sort results by the cosine similarity[1] between vectors. The idea is that you can attach a vector to documents in the database and then when you pass a vector in the query and get back documents that most match the query vector.
The function that creates these vectors(string -> vector) is called an embedding and is constructed in such a way that "semantically similar" strings have vectors that are close together.
It's not a very complicated idea, but complicated and powerful are orthogonal concepts.
They are useful in AI(LLMs) when you would like to include documents in your prompt that are relevant to your instruction. The best way to describe this is by example.
Imagine your query is "What is the capital of France?" Rather than requiring your LLM to encounter this fact during its training, you can embed the question("What is the capital of France?" and retrieve documents (say you've indexed all of Wikipedia in your vector db) and return some snippets from articles that include this information(context).
You then pass the the prompt+context to an LLM and given that it now has relevant information, it can answer the question.
You can also imagine that it's much easier to update a vector db with new information than it is to retrain a model to ingest new facts.
Re: Every database will become a vector database sooner or later
#106Earlier quoted context omitted.
Well you could store numbers all fine, but indexing vectors for similarity queries seems fairly recent and not all that widespread in the transactional world. As the traditional db move forward in the space the need for dedicated vector databases will likely shrink, except for some very specific implementation that offer unique enough features (I.e. deeplake does vector search over object storage, which is very conve…
How is indexing a vector different from indexing a varchar or an integer ? If you convert a vector into a byteaarray it should be no different from a bytearray of varchar but for the bytearray contents. Now if you want to do similarity search you have to measure the distance between 2 or more vectors and that's independent of the indexing. No ? So any database with sufficient memory should be able to accomplish this…
Indexing in a vector engine is what gives you similarity search faster than brute force. The type of engine is what gives you various different distance measures (often approximate). Redis specifically has two choices: brute force (which is precise and slow), or HNSW (which is approximate and fast, but space-consuming for interesting dimensionality).
Re: Every database will become a vector database sooner or later
#107I still haven't figured what a vector DB is, beyond something something AI.
Imagine: you need a data structure which allows you to store vectors in memory and then say "here is a vector A, give me the 10 vectors which are closest to the same direction of this vector A, in n dimensional space".
One can imagine there is some optimal way to lay out the data in memory such that it would be relatively quick to do that. One can imagine a naive way to do it which probably wouldn't be fast. A vector DB does the first thing - lays out the data in a way which then enables it to do that fast.
And then it does all the other stuff a DB does - persisting to disk (which means data needs to be laid out in a sensible way on disk too), handling multiple queries, updates, and the 50 other complicated things databases tend to do. Users generally want to do other operations on vector as well so a vector DB does those too.
For a small number of vectors you can build a vector DB yourself. Write a list of vectors to a file, load them into memory in no particular order, then for your "n closest" function, just iterate through the list calculating the difference in direction one by one and keeping the top n. Your simple system will work just fine for a toy demo.
Re: Every database will become a vector database sooner or later
#108Earlier quoted context omitted.
> compared to the last db hype of NOSQL NoSQL has been around for over 20+ years. Since then Cassandra, DynamoDB, FoundationDB, MongoDB, Neo4J, Redis etc are not only still around but widely used and powering many of the services you use today.
The difference is that today those DBs are generally considered as complements to SQL databases targeting specific use cases. Back in the peak NoSQL days people were pushing the narrative that you'd never need to use a SQL database for anything ever again.
Oh, they're still at it. In my relatively recent experience Mongo will still try to sell you on the idea of abandoning relational workloads because migrations are hard and schemas are optional.
Re: Every database will become a vector database sooner or later
#109Maybe I’ve been using PostgreSQL too long but when faced with the choice of adding vector support to PostgreSQL or using a new technology, my first choice was to start with the PostgreSQL addition. I’m not criticizing the specialized case for a true vector database, but for most workloads I agree that the big database players will be the right choice for many users.
Pgvector's 2000-dimension limit on vector indices is annoying. There are workloads I want to push at it which are in the 5000+ range, so there's an extra dimensionality reduction step I need to build.
My starting point for pretty much any storage problem is "have you tried throwing it in postgresql" but this is one reason pulling something else off the shelf might be a good idea.
Re: Every database will become a vector database sooner or later
#110I still haven't figured what a vector DB is, beyond something something AI.
Wow you are so right. I just typed “best vector database” on Google and I have 4 ads with other results all talking about “vector database something AI”.