Every database will become a vector database sooner or later • Hacker News Board

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

#91

Post by vinay_ys » Tue, Oct 03, 2023, 1:33 PM UTC

The argument that combining traditional database and vector database into one because it reduces data movement doesn't compute for me.

Firstly, even for non vector data, read/write transactional database vs read-optimized store purely for fast serving are already markedly different. Then, the shape of data that is used to generate embeddings is markedly different than the shape of data that is ready to transact or serve.

So, no matter where it is stored, it has to leave that store, get transformed and enriched and then run through an embeddings generator (ML inference).

Then, it has to be stored in a manner that is optimal for retrieval ranking. If you are doing ANN that's one thing, but if you are doing attribute based filtering while retrieving and you wish to accelerate it through GPU to do more exhaustive search, that's another thing altogether.

All these lead to fairly sophisticated optimized implementation. Sure, a singular database product solution that has all these different optimized engines can emerge over time but surely it is too early today to converge like this.

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

#92

Post by weird-eye-issue » Tue, Oct 03, 2023, 1:36 PM UTC

hobs wrote: post #81

BoorishBears wrote: post #60

Earlier quoted context omitted.

Bloat your DB... or pull in an entirely new vendor and bloat your entire operational outlay. I'd really love to know what kind of insane scale justifies that tradeoff...

Don't forget your latency!

They are separate systems. We don't touch Postgres for the same code that needs to access Pinecone.

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

#93

Post by weird-eye-issue » Tue, Oct 03, 2023, 1:37 PM UTC

crazy_marksman wrote: post #41

weird-eye-issue wrote: post #19

Earlier quoted context omitted.

Exactly. We use Supabase too but are at a scale where it just made sense to use a second, dedicated vector db (Pinecone) than to bloat our Postgres db that has a completely different workload

How do you deal with security and access control across postgres and pinecone?

We use Cloudflare Workers for our API and just handle auth calls by checking the JWTs with Supabase and caching it. So we already had the necessary auth setup to do this.

For basic CRUD we use the Supabase endpoints directly but none of that involves querying a vector db :P

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

#94

Post by weird-eye-issue » Tue, Oct 03, 2023, 1:38 PM UTC

BoorishBears wrote: post #60

weird-eye-issue wrote: post #19

Earlier quoted context omitted.

Exactly. We use Supabase too but are at a scale where it just made sense to use a second, dedicated vector db (Pinecone) than to bloat our Postgres db that has a completely different workload

Bloat your DB... or pull in an entirely new vendor and bloat your entire operational outlay. I'd really love to know what kind of insane scale justifies that tradeoff...

That's a very exaggerated way to look at things lol. Nothing got bloated at all in this process, we are just using the right tools for the job. I'm a solo founder and the only backend developer. I can assure you this decision only made my life easier by choosing the correct tech from the get go.

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

#95

Post by eggy » Tue, Oct 03, 2023, 1:48 PM UTC

As a lover of array languages, I remember being excited to read a futurist article on vector processors and programming languages. It was written right before Wes McKinney worked on Pandas (the J programming language influenced him), and I thought J/APL or another array language was going to explode. J has Jd, in which J is fully integrated. This did not come to pass (yet). No matter, I still enjoy array languages anyway. There's a new array language, uiua[1], that is a mix of array and stack concepts with a good standard library including audio and graphics.

[1] https://www.uiua.org/

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

#96

Post by beanjuiceII » Tue, Oct 03, 2023, 1:58 PM UTC

eggy wrote: post #95

As a lover of array languages, I remember being excited to read a futurist article on vector processors and programming languages. It was written right before Wes McKinney worked on Pandas (the J programming language influenced him), and I thought J/APL or another array language was going to explode. J has Jd, in which J is fully integrated. This did not come to pass (yet). No matter, I still enjoy array languages an…

uiua looks like a perl programmer went mad

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

#97

Post by nwsm » Tue, Oct 03, 2023, 2:05 PM UTC

beanjuiceII wrote: post #96

eggy wrote: post #95

As a lover of array languages, I remember being excited to read a futurist article on vector processors and programming languages. It was written right before Wes McKinney worked on Pandas (the J programming language influenced him), and I thought J/APL or another array language was going to explode. J has Jd, in which J is fully integrated. This did not come to pass (yet). No matter, I still enjoy array languages an…

uiua looks like a perl programmer went mad

It looks like array/stack Brainfuck.

Previous uiua discussion: https://news.ycombinator.com/item?id=37673127

Brainfuck: https://en.wikipedia.org/wiki/Brainfuck

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

#98

Post by jjtheblunt » Tue, Oct 03, 2023, 2:13 PM UTC

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.

What would you use to compute proximity of vectors, for example?

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

#99

Post by rpcope1 » Tue, Oct 03, 2023, 2:48 PM UTC

mattew wrote: post #78

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.

I'm in the same boat. For things that aren't huge scale, it's almost easier to find an extension or otherwise beat Postgres (or SQLite or Percona MySQL) into submission for your use case. Timescale is a really good example...I was really impressed how good the performance was for bigish (1 TB+) real time scientific time series data, even on a cheap Amazon Lightsail instance.

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

#100

Post by hoosieree » Tue, Oct 03, 2023, 2:50 PM UTC

nwsm wrote: post #97

beanjuiceII wrote: post #96

Earlier quoted context omitted.

uiua looks like a perl programmer went mad

It looks like array/stack Brainfuck. Previous uiua discussion: https://news.ycombinator.com/item?id=37673127 Brainfuck: https://en.wikipedia.org/wiki/Brainfuck

Appearances can be deceiving. In terms of expressiveness, Uiua is to Brainfuck as Python is to nand.