Can you do a compare/contrast with CozoDB?
Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
61–70 of 117 posts
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#62"faster than Neo4j" How does it compare to Dgraph?
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#63The fact that it's "backed by NVIDIA" and licensed under AGPL-3.0 makes me wonder about the cost(s) of using it in production.
Could you share any information on the pricing model?
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#64How scalable is your DB in your tests? Could it be performent on graphs with 1B/10B/100B connections?
So far, we've tested it for up to ~10B connections and 50 odd million nodes. We didn't run in to any problems with it yet.
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#65What would be a typical/recommended server setup for using this for RAG? Would you typically have a separate server for the GPUs and the DB itself?
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#66"faster than Neo4j" How does it compare to Dgraph?
We don't have any benchmarks against them but from what I've just read about there bench marks, we should be just as good as them.
That is just heresy though, am interested myself now and will run some proper benchmarks
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#67I spent a bit of time reading up on the internals and had a question about a small design choice (I am new to DB internals, specifically as they relate to vector DBs).
I notice that in your core vector type (`HVector`), you choose to store the vector data as a `Vec`. Given what I have seen from most embedding endpoints, they return `f32`s. Is there a particular reason for picking `f64` vs `f32` here? Is the additional precision a way to avoid headaches down the line or is it something I am missing context for?
Really cool project, gonna keep reading the code.
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#68Graph DB OOMing 101. Can it do Erdős/Bacon numbers? Graph DBs have been plagued with exploding complexity of queries as doing things like allowing recursion or counting paths isn't as trivial as it may sound. Do you have benchmarks and comparisons against other engines and query languages?
No, we are in the process of writing up some proper benchmarks. Our first user used us to build MuskMap and TrumpMap, which went viral on twitter. Not sure how it compared to other graph DBs at the time (bear in mind this was v1 and very bear bones), but it got latency of using Postgres >5s down to 50ms with us.
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#69The fact that it's "backed by NVIDIA" and licensed under AGPL-3.0 makes me wonder about the cost(s) of using it in production. Could you share any information on the pricing model?
We are open-source, so you can use and self host us for free. Our plan is to create a managed service (so long as all goes well) which shouldn't be priced any differently from other databases in the space.
We chose AGPL to make sure someone can't make a cloud hosted version of our product, think MongoDB on AWS a few years back.
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#70Excellent work. Very exited to test this out. What are the limits or gotchas we should be aware of, or how do you want it pushed? What other papers did you get inspiration from?
Thanks for the kind words! At the moment the query language transpilation is quite unstable but we are in the process of a large remodel which we aim to finish in the next day or so. This will make the query language compilation far more robust, and will return helpful error messages (like the rust compiler).
The other thing is the core traversals are currently single threaded, so aggregating huge lists of graph items can take a bit of a hit. Note however, that we are also implementing parallel LMDB iterators with the help of the meilisearch guys to make aggregation of large results much faster.