Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every database will become a vector database sooner or later

nextword.substack.com

Post reply on HN
Print view View original

71–80 of 143 posts

Re: Every database will become a vector database sooner or later

#71

Post by d_watt »

mr_toad wrote: post #23
esafak wrote: post #4

> It genuinely makes sense for incumbent database players to offer vector search, because that eliminates unnecessary data movement to separate vector databases. Co-locating vectors and original documents also reduces latency. Yet OLAP databases continue to thrive alongside OLTP databases, the nascence of NewSQL hybrid (HTAP) databases notwithstanding. Different needs dictate different design choices for optimality.

Is anyone considering a new OLAP system these days? If “NewSQL” (which seems to be a fancy buzzword for running analytics in your transactional database) takes off wont it be the final nail in the coffin for OLAP?

"NewSQL" is not about analytical performance, it's about multimaster distributed writes and reads. EG, you don't want to run count(*) on spanner.

"HTAP" is the buzzword you're looking for. It's promising, but also complex and nascent. It'll be interesting to see how much traction it gets over time, but things like TiDB and Unistore are pretty early on to call a nail in the coffin for redshift/bigquery/clickhouse etc.

Re: Every database will become a vector database sooner or later

#72

Post by da_chicken »

threeseed wrote: post #54
mnky9800n wrote: post #34

Earlier quoted context omitted.

To be fair, Vector databases does sound more official as "new and important technology" compared to the last db hype of NOSQL.

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

That's true, but 13 or 14 years ago, the NoSQL hype was calling for widespread abandonment of RDBMSs. They were claiming key-value stores and document databases would replace traditional relational databases the same way Reddit replaced Digg. That "MongoDB is web scale" video was lampooning the very real hype that people had, and how difficult it was to pick through it. It was as bad as the more recent blockchain hype.

Even looking at HN's reactions to that video show a few comments that did not age very well (although most of them did): https://news.ycombinator.com/item?id=1636198

The sensible takes were that NoSQL would supplement and enhance RDBMSs, but the hype was much more than that.

Re: Every database will become a vector database sooner or later

#73

Post by deepGem »

avereveard wrote: post #17
loondri wrote: post #14

I think the move towards vector databases might be more hype than necessity. Traditional databases, when properly optimized, can handle vector data for many use cases. The push for specialized vector databases could be re-evaluated in terms of efficiency and cost-effectiveness compared to optimizing existing scalar databases.

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 as evidenced by the vector similarity search feature of Redis. ( I don't know how Redis folks have implemented vector similarity but they do support KNN search )

Re: Every database will become a vector database sooner or later

#74

Post by dagw »

threeseed wrote: post #54
mnky9800n wrote: post #34

Earlier quoted context omitted.

To be fair, Vector databases does sound more official as "new and important technology" compared to the last db hype of NOSQL.

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

Re: Every database will become a vector database sooner or later

#75

Post by deepGem »

avereveard wrote: post #63
thesz wrote: post #43

Earlier quoted context omitted.

What is "vector search over object storage?" Does deeplake performs some computations on objects and search on their embeddings?

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 something like {"1123124234": "obj1"} ?

From what I understand the query will be "geography" whose embedding will be "12311111" and now you have to run a KNN for a match which will return {"name": "atlas", "embedding": "1123124234"}

Not sure where the embedding index comes into play here.

Re: Every database will become a vector database sooner or later

#76

Post by jbird11 »

Lots of focus on RAG here, and rightfully so, but I feel an overlooked benefit to vector databases is the novel visualizations they provide. To be able to plot qualitative data onto a 2d graph with tsne reduction provides a new method with which to draw insights from. I think many companies would benefit from such a visualization tool, especially those in qualitative research.

Re: Every database will become a vector database sooner or later

#77

Post by rakoo »

smitty1e wrote: post #48
Guvante wrote: post #38

Earlier quoted context omitted.

I mean NOSQL was hype with no substance but "you can scale more if you deal with not having ACID" is just generally true. Of course ACID scales to well into the Fortune 500 scale so...

"No substance" seems a bit harsh. They mostly seem a tarted up associative array, sure, but a key-value store is a thing.

A naturally distributed key/value store. NoSQL wasn't a product, it was a radical rethinking of the balance between what we wanted and what we needed. Turns out some absolute necessities of using a RDBMS or even using SQL are not that important, and relaxing those actually-not-requirements allows massive scalability, something we desperately needed, or some evolved data structures and computation, like what redis provides.

Re: Every database will become a vector database sooner or later

#78

Post by mattew »

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

Re: Every database will become a vector database sooner or later

#79

Post by modulovalue »

KirillPanov wrote: post #55
mattashii wrote: post #51

Earlier quoted context omitted.

r*-trees work doesn't work well when the number of dimensions stored in the index is much higher than the logarithm of the number of indexed entries, and this is a prevailing property of divide-and-conquer spatial index types when the keyspace is divided based on a single dimension at a time. As vectors regularly have 100+ dimensions, normal spatial indexing methods applied to vectors wouldn't be very efficient for a…

Also the distance metric for r*-trees is just plain wacky for anything other than low-dimensional Euclidean space. Even if you could make it perform well, it would not do what you want.

Are you saying this because r-trees expect a proper metric space, and people have the need to index datasets over non-metric spaces?

Re: Every database will become a vector database sooner or later

#80

Post by sgarland »

deepGem wrote: post #73
avereveard wrote: post #17

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

Mostly the number of dimensions. Assuming your vectors are float16, so 2 bytes each, you’d run into Postgres’ B+tree index limit (2704 bytes) very quickly. You could index a 512-dimension vector fine, but I believe most models are well beyond that.

There are alternative index types, of course, or you could index the hash of the vector. These both come with tradeoffs.

Post reply on HN