how did you get it 3 OOMs faster than neo4j?
On comparable benchmarks with comparable guarantees? Comparable persistence levels? I’m very skeptical.
Looking forward to putting you at ease :) Working on some proper benchmarks over the next few days.
Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
71–80 of 117 posts
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#72Looks very interesting, but I've seen these kind of multi-paradigm databases like Gel, Helix and Surreal and I'm not sure that any of them quite hit the graph spot. Does Helix support much of the graph algorithm world? For things like GrapgRAG. Either way, I'd be all over it if there was a python SDK witch worked with the generated types!
We started as a graph database, so that's definitely the main thing we want to get right and we wan't to prioritise capturing all that functionality.
We have a python SDK already! What do you mean by generated types though?
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#73What 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?
Assuming you are using GPUs for model inference, the best way to set it up would have the DB and a separate server to send inference requests. Note that we plan on support custom model endpoints and on the database side so you probably won't need the inference server in the future!
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#74Can you do a compare/contrast with CozoDB? https://github.com/cozodb/cozo
apart from the fact Cozo seems to be pretty dead, we use a different storage engine which makes our reads much faster. based on their benchmarks I estimate our most of our reads to be 10x faster. I think our query language is much simpler, and easy to understand than Datalog which is what they use.
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#75I 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 addition…
thanks for the question! we chose f64 as a default for now as just to cover all cases and we believed that basic vector operations would not be our bottleneck initially. As we optimize our HNSW implementation, we are going to add support for f32 and binary vectors and drop using Vec and instead use [f64/f32; {num_dimensions}] to avoid unnecessary heap allocation!
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#76Congrats! Any chance Helixdb can be run in the browser too, maybe via WASM? I'm looking for a vector db that can be pre-populated on the server and then be searched on the client so user queries (chat) stay on-device for privacy / compliance reasons.
to add to George's reply, for helix to run on the browser with WASM the storage engine has to be completely in memory. At the moment we use LMDB which uses file based storage so that does't work with the browser. As George said, we plan on making our own storage engine and as part of that we aim to have an in-memory implementation.
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#77Earlier quoted context omitted.
Looks really interesting, I'll have a proper read. What would be your reasoning to incorporate this if we already have vector functionality and semantic search?
my project deals w/ non-english text, bm25 performance is middeling. Language specific sparse model helps.
We will definitely look into it. The SPLADE models look promising!
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#78Congrats! Any chance Helixdb can be run in the browser too, maybe via WASM? I'm looking for a vector db that can be pre-populated on the server and then be searched on the client so user queries (chat) stay on-device for privacy / compliance reasons.
to add to George's reply, for helix to run on the browser with WASM the storage engine has to be completely in memory. At the moment we use LMDB which uses file based storage so that does't work with the browser. As George said, we plan on making our own storage engine and as part of that we aim to have an in-memory implementation.
Not entirely sure if you could use it, but wondering if you’ve heard about the origin private file system feature of modern browsers? https://developer.mozilla.org/en-US/docs/Web/API/File_System...
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#79Looks very interesting, but I've seen these kind of multi-paradigm databases like Gel, Helix and Surreal and I'm not sure that any of them quite hit the graph spot. Does Helix support much of the graph algorithm world? For things like GrapgRAG. Either way, I'd be all over it if there was a python SDK witch worked with the generated types!
Shameless plug: If you're exploring graph+vector databases, check out https://github.com/Pometry/Raphtory/ — with a full Python SDK and built-in support for most common graph algorithms.
It’s built in Rust with native vector support. The open-source version is in-memory, but the commercial version supports disk-based scaling (we tested it with a 3TB graph on an M1 MacBook + insert all 100x faster than existing GraphDBs).
Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)
#80Earlier quoted context omitted.
to add to George's reply, for helix to run on the browser with WASM the storage engine has to be completely in memory. At the moment we use LMDB which uses file based storage so that does't work with the browser. As George said, we plan on making our own storage engine and as part of that we aim to have an in-memory implementation.
Not entirely sure if you could use it, but wondering if you’ve heard about the origin private file system feature of modern browsers? https://developer.mozilla.org/en-US/docs/Web/API/File_System...
very interesting, will look into this. I know for a fact that you cannot compile the likes of LMDB and RocksDB to work with WASM but this looks promising for our custom storage engine to be able to make it work with the browser. Thanks for this!