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

21–30 of 143 posts

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

#21

Post by taeric »

barrkel wrote: post #15
appplication wrote: post #6

Earlier quoted context omitted.

It’s interesting that I never considered why OLTP and OLAP are basically orthogonal technologies. Are there any major players that have an integrated solution for both? I guess it makes sense because the infra is so different, but I’m not sure whether it need be.

Effecient OLAP queries need a different shape of data - some combination of columnar storage for efficient scanning, and roll-up tables with pre-aggregated measures. Even in an integrated scenario, behind the scenes there will need to be a bunch of copying to transpose and / or refresh roll-ups.

The pre-aggregation is one too many try and skip. People seem to think they can build a single schema to rule all things, and then assume they can quickly calculate any aggregation on demand.

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

#23

Post by mr_toad »

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?

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

#24

Post by sgu999 »

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…

sqlite has r-trees for instance [0]. Could it be good enough for most use cases? If it's to query a knowledge base for instance, a couple dimensions should be sufficient. With the added benefit of being able to query your data in other ways.

[0] https://www.sqlite.org/rtree.html

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

#25

Post by Foobar8568 »

beoberha wrote: post #11
shri_krishna wrote: post #8

The one DB fits all approach only works when the size of the database is really small and never grows. Imagine you have 100 customers. Each customer generates, on average, a million 1536 dimension vector embeddings (considering OpenAI Ada dimensions which is the most popular right now). That is 6GB (1536 x 4 bytes per dimension for f32 x 1000_000) of just embeddings PER CUSTOMER. If you use HNSW it will take at least…

Exactly - vector indexes are so different than traditional RDBMS B-Tree or LSM Tree indexes that it doesn’t make sense to use the same store for both unless it’s basically a toy app. Someone makes the example in another comment, but it’s analogous to OLTP vs OLAP

I don't even want to imagine the workload on a high txn OLTP mixed with OLAP access pattern. IMHO If you can, you don't need OLAP in the first place.

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

#26

Post by _pdp_ »

I do agree with the article that this feature will be more or less available in all DB types.

Vector databases are a gimmick at the moment. Ultimately conversational AI agents should be able to extract information from a diverse set of sources with a diverse set of tools. The approach that is currently taken is hit-and-miss at best. How often do you searched something and the first result happens to be the thing you are looking for? Why should it be any different with vector DBs? Obviously the query matters a lot no matter how the information is searched.

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

#27

Post by charcircuit »

aiappreciator wrote: post #13

It is true that every major DB ventor, SQL or not, is smashing the AI/vector keyword on their front pages. In Elastic for example, their vector capabilities have gone from laughable to respectable in a year. Its a lot simpler to just use one DB instead of many. But a question for true DB experts here: 1. Is there any real advantage to building a dedicated vector DB from scratch? 2. Is vector DB something that can be…

The trade off that you are interested in isn't about storing vectors, but rather about whether an index should be a part of the DBMS or external to it.

Some advantages of having a separate index is that it can work with different backends, it can be independently scaled, and it can index data for more than 1 database server.

Some disadvantages are increased latency, increased complexity, and distributed system problems.

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

#28

Post by totetsu »

shri_krishna wrote: post #8

The one DB fits all approach only works when the size of the database is really small and never grows. Imagine you have 100 customers. Each customer generates, on average, a million 1536 dimension vector embeddings (considering OpenAI Ada dimensions which is the most popular right now). That is 6GB (1536 x 4 bytes per dimension for f32 x 1000_000) of just embeddings PER CUSTOMER. If you use HNSW it will take at least…

Are there any DB that could support both use cases while being able to partition them in such a way that the transactions etc are only kept on part of the resources they need to be. Basically two seperated DBs but sharing the same interfaces and security etc.

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

#29

Post by pmm »

I think just as with full-text search, vector search, if supported, will be full of tradeoffs for general purposes databases.

The view that everything needs to support direct input for generative AI is short sighted. There are other use cases as well. Even if ultimately these will become just building blocks for whatever AGI there comes. Horses for courses

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

#30

Post by xvinci »

appplication wrote: post #6
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.

It’s interesting that I never considered why OLTP and OLAP are basically orthogonal technologies. Are there any major players that have an integrated solution for both? I guess it makes sense because the infra is so different, but I’m not sure whether it need be.

I think they have, they are just not that well known. E.g. SQL Server - https://learn.microsoft.com/en-us/sql/relational-databases/i... - you can also find quite a lot of papers by microsoft employees on the designs and capabilities (starting around 2016 I believe, so "pretty new"). I have used it with TPC-H and it worked wonders, never got around to using it in a production workload though.
Post reply on HN