Re:Vector database is not a separate database category
by sgarland on Tuesday October 03, 2023 @08:50AM
(#37751161)
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.
Re:Vector database is not a separate database category
by smilliken on Tuesday October 03, 2023 @02:55PM
(#37756014)
Btree isn't a very useful index type for a vector, though. GIN, GIST, and the handful of new extensions optimizing for vector search are what you'd want (and don't have this limitation).
Aside, you can increase the size of tuples you can index in a postgresql btree by increasing the postgresql page size (requires a recompile and creating a new database instance).
Re:Vector database is not a separate database category
by sgarland on Tuesday October 03, 2023 @05:47PM
(#37758029)
Agreed to the first, but you have to first know that those exist (and what they’re good for). This leads into my second point: IME, the Venn diagram for “people making AI stuff” and “people capable of compiling and running their own DB in a reliable manner” has no overlap.
Re:Vector database is not a separate database category
by JustLurking2022 on Tuesday October 03, 2023 @09:19AM
(#37751448)
The distance computation could be separate from the indexing, but it will be inefficient relative to having an index organized to support the task.
Re:Vector database is not a separate database category
by regularfry on Tuesday October 03, 2023 @11:16AM
(#37753043)
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).
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 )