Re:The PlanetScale vectors public beta
by Temporary_31337 on Tuesday October 22, 2024 @06:46PM
(#41919492)
I work for another db vendor and we also have added vectors support. What’s crazy is that customers were not really asking for- just surfing the hype wave like everyone else. Why would someone store vectors in an SQL db rather than a dedicated vector db with support for native graph / vector semantics?
[ Parent
| on HN ]
Are you asking why you did it?
For one thing, combining vector similarity ranking and traditional WHERE clause conditions in the same query is tremendously useful.
“This customer has called our support line 20 times in the past year, pop up the most relevant prior tickets to their current request.”
Re:The PlanetScale vectors public beta
by doomroot on Wednesday October 23, 2024 @11:41AM
(#41926187)
applying to yc with this idea.
Re:The PlanetScale vectors public beta
by redwood on Wednesday October 23, 2024 @06:39AM
(#41923659)
I'd ask the opposite: why would you use a vector index without the related metadata for filtering and hybrid querying. People don't use B-Tree indexes as a standalone separate database off to the side of their database. So why should they for vectors?
Because you can transact over relational and vector operations. You have to strongly justify why you're not storing data in your dbms because you lose the ability to atomically update them both.
In most cases the justification is performance and that the data is ephemeral but people want to store vectors in lock-step with their data.
Re:The PlanetScale vectors public beta
by alittletooraph2 on Wednesday October 23, 2024 @02:00PM
(#41927630)
b/c you don't want the management or learning curve overhead of a separate database for vectors than the one you're already using for transactions or metadata