11–20 of 26 posts
Vector databases seem to be a dime a dozen, now, as well as being built into Elasticsearch and available as Postgres extensions. As far as I know they’re all relatively undifferentiated in performance and features. Is there a viable long-term business here?
Why did you choose SpeedANN instead of other new indexes such as DiskANN? And you changed the color of epsilla in every benchmark figure, which is quite confusing
imho, vectorDbs need to scale horizontally. Simply running on a single host doesn't cut it anymore.
Regarding the embedding vectors - is there a maximum limit to their dimensionality? Also, can you share insights into how the precision remains consistent at 99.9% even with high-dimension vectors?
I'm curious about your approach on where you draw the line for database features; I don't have a perspective on what's right, just trying to get informed. There are a bunch of possible areas to circle or ignore when making an ML-capable database of some sort. In rough order of data complexity: 1. Embeddings (context-free vectors, just an ID and the vector) 2. Metadata + Embedding (source data, JSON) 3. Binary Data +…
For the database perspective, instead of dividing the table schema into 3 parts: id, metadata, embedding, we designed in a way closer to SQL, treat vector as another data type, and let user to define any number of fields in a table. ID is just an annotation of a field (composite key might be overkilling for now). There will be another debate on whether schemaful or schemaless is the right approach, we can leave it here for now
With this foundation, we already covers 1 and 2. And in our roadmap we also plan to cover 3, with multi-modal data type support. We think the real big advantage of embedding is on unstructured data (documents, images, video, audio, etc), and storing the embedding of multi-modal data and connect them through semantic relevance will open up big opportunities. And this fits with the table and fields-based design for introducing cross table embedding index on connecting different shape data.
And from the multi-modal data perspective comes the problem where do we store those data? One way is we provide a generic binary data type that let users put anything. Another way which most enterprise will do is integrate us with a larger data warehouse/data lake system. And this opens up the requirement for us on supporting data streaming in/out with kafka connector, spark connector, etc.
And totally agree that SQLite works so well in huge amount of scenarios, now there is DuckDB. We also see some other players like LanceDB taking this approach to be Vector DB space's SQLite. We are also pretty close to announce our Python in-process package support, so docker / a separate server is not a must have anymore.
For inference, this is a broader direction for us for now. We are open to explore this space and see if the serverless architecture on cloud can provide extra efficiency benefit to the market
“Hippocampus of AI” in a readme is a yellow flag
Maybe drop the disingenuous marketing and find something else to work on. The 50 other vector dbs will implement this trivial addition and you'll be left with nothing to show.
Sources: https://arxiv.org/abs/2201.13007 https://dl.acm.org/doi/pdf/10.1145/3572848.3577527