Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

github.com

Post reply on HN
Print view View original

101–110 of 117 posts

Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

#101

Post by [deleted] »

mauvo59 wrote: post #99
GeorgeCurtis wrote: post #59

Earlier quoted context omitted.

Neo4j first of all is very slow for vectors, so if performance is something that matters for your user experience they definitely aren't a viable option. This is probably why Neo4j themselves have released guides on how to build that middleman software I mentioned with Qdrant for viable performance. Furthermore, the vectors is capped at 4k dimensions which although may be enough most of the time, is a problem for som…

Hey, want to correct some of your statements here. :-) Neo4j's vector index uses Lucene's HNSW implementation. So, the performance of vector search is the same as that of Lucene. It's worth noting that performance suffers when configured without sufficient memory, like all HNSW vector indexes. >> This is probably why Neo4j themselves have released guides on how to build that middleman software I mentioned with Qdrant…

[deleted]

Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

#102

Post by xavcochran »

quantike wrote: post #100
xavcochran wrote: post #75

Earlier quoted context omitted.

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!

I appreciate the reply! Yeah that sounds like the correct path forward is swapping out the type for some enum of numeric types you want to cover. I'd be curious if there's some benefit to the runtime-memory utilization to baking in the precision of the vector if it's known at comptime/runtime. In my own usage of vector DBs I've only ever used a single-precision (f32), and often have a single, known dimension. But if…

The benefit of baking in the dimension and size of individual elements (the precision) is the fact that the size will be known at compile time meaning it can be allocated on the stack instead of being heap allocated.

Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

#103

Post by mattturck »

GeorgeCurtis wrote: post #40
basonjourne wrote: post #28

why not surrealdb?

General consensus is it's really slow, I like the concept of surreal though. Our first, and extremely bare bones, version of the graph db was 1-2 orders of magnitude faster than surreal (we haven't run benchmarks against surreal recently, but I'll put them here when we're done)

I don't think that's all the general consensus

Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

#104

Post by GeorgeCurtis »

datastorydesign wrote: post #85
GeorgeCurtis wrote: post #40

Earlier quoted context omitted.

General consensus is it's really slow, I like the concept of surreal though. Our first, and extremely bare bones, version of the graph db was 1-2 orders of magnitude faster than surreal (we haven't run benchmarks against surreal recently, but I'll put them here when we're done)

Hey George, Alexander from SurrealDB here. Congratulations on the launch! This is a very exciting space, and it's great to see your take on it. Running fair benchmarks, not benchmarketing, is a significant effort and we recently put in this effort to make things as fair and transparent as possible across a range of databases. You can see the results and links to our code in the write-up here: https://surrealdb.com/bl…

I've only just seen this! Thanks so much for the response, would definitely love to chat with you guys.

You're definitely right btw, those weren't concrete benchmarks and I'm excited to see how we compare now :)

Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

#105

Post by GeorgeCurtis »

mattturck wrote: post #103
GeorgeCurtis wrote: post #40

Earlier quoted context omitted.

General consensus is it's really slow, I like the concept of surreal though. Our first, and extremely bare bones, version of the graph db was 1-2 orders of magnitude faster than surreal (we haven't run benchmarks against surreal recently, but I'll put them here when we're done)

I don't think that's all the general consensus

I was just going off of what we've heard from users and people in the space, I admit that "general consensus might've been the wrong terminology.

Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

#106

Post by GeorgeCurtis »

mauvo59 wrote: post #99
GeorgeCurtis wrote: post #59

Earlier quoted context omitted.

Neo4j first of all is very slow for vectors, so if performance is something that matters for your user experience they definitely aren't a viable option. This is probably why Neo4j themselves have released guides on how to build that middleman software I mentioned with Qdrant for viable performance. Furthermore, the vectors is capped at 4k dimensions which although may be enough most of the time, is a problem for som…

Hey, want to correct some of your statements here. :-) Neo4j's vector index uses Lucene's HNSW implementation. So, the performance of vector search is the same as that of Lucene. It's worth noting that performance suffers when configured without sufficient memory, like all HNSW vector indexes. >> This is probably why Neo4j themselves have released guides on how to build that middleman software I mentioned with Qdrant…

Thanks for clearing up some of these points. Really pleased the post has reached the industry leaders, and I genuinely appreciate your response :)

With regards to the prefiltering, I was referring to filtering during the neighbor search in the HNSW. If you wanted 10 vectors, but with specific conditions, you'd have to retrieve surplus vectors and then perform the filter, hoping you were left with enough. Does that sound right? I suppose that is metadata filtering.

I should've been more specific about the memory issue. Not tying to slate you here, just that a lot of complaints I've read online were about issues with memory overflows using the vectors. But of course, a misconfigured system would definitely perform poorly :)

Thanks again for the response!

Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

#107

Post by rationably »

GeorgeCurtis wrote: post #69
rationably wrote: post #63

The 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.

I can use it for personal needs, sure. Bringing AGPL in a closed-source project is a no go for obvious reasons.

Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

#108

Post by GeorgeCurtis »

rationably wrote: post #107
GeorgeCurtis wrote: post #69

Earlier quoted context omitted.

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.

I can use it for personal needs, sure. Bringing AGPL in a closed-source project is a no go for obvious reasons.

We built this to help people make software that was previously harder to make. If people want to build software and share it with everyone, they are welcome to do that for free, and if someone wants to close-source their project to make lots of money, then they can support the community they rely on by paying a license. :)

Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

#109

Post by wontonaroo »

GeorgeCurtis wrote: post #5
esafak wrote: post #4

How does it compare with https://kuzudb.com/ ?

Kuzu don't support incremental indexing on the vectors. The vector index is completely separate and decoupled from the graph. I.e: You have to re-index all of the vectors when you make an update to them.

Firstly congratulations on your effort.

How does the graph component of your database perform compared to Kuzu? Do you have any benchmarks.

For RAG I've tried Qdrant, Meilisearch, and Kuzu. At the moment I wouldn't consider HelixDB because of HelixQL. Wondering why you didn't use OpenCypher?

At the moment you have this system which is aimed to support AI/LLM systems but by creating HelixQL you do not have an AI coding friendly query language.

With OpenCypher even older cheap models can generate queries. Or maybe some GraphQL layer.

Re: Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

#110

Post by GeorgeCurtis »

wontonaroo wrote: post #109
GeorgeCurtis wrote: post #5

Earlier quoted context omitted.

Kuzu don't support incremental indexing on the vectors. The vector index is completely separate and decoupled from the graph. I.e: You have to re-index all of the vectors when you make an update to them.

Firstly congratulations on your effort. How does the graph component of your database perform compared to Kuzu? Do you have any benchmarks. For RAG I've tried Qdrant, Meilisearch, and Kuzu. At the moment I wouldn't consider HelixDB because of HelixQL. Wondering why you didn't use OpenCypher? At the moment you have this system which is aimed to support AI/LLM systems but by creating HelixQL you do not have an AI codin…

Thanks for the support :)

We're currently working on benchmarks so nothing exact on Kuzu right now with regards to performance. We've had quite a few requests for benchmark comparisons against different databases, so they should take a good few days. Will return here when they are ready

When we've used Cypher in the past we didn't get on with the methodology of the language that well. A functional approach, like gremlin, suited our minds better. But, Gremlin's syntax is awful (in our opinion), and the amount of boilerplate code you need we felt was unnecessary.

We wanted to make something that was easier to read than Gremlin, like Cypher, but also have functional aspect that just made traversals feel so much more intuitive.

Another note, we're more fond of type-safe languages, and it didn't make much sense to us that out of all the programming languages that exist, query languages were the non-type-safe ones.

We know it's a pain learning a new language, but we really believe that our approach will pave the way for a better development experience and a better paradigm.

Onto the AI stuff, you're right, it isn't ideal (right now). We did make a gpt wrapper that did a pretty good job of writing queries based on a condensed version of our docs, but this isn't ideal. So, the next thing on our road map is a graph traversal MCP tool. Instead of the agent having to generate text written queries, it can use the traversal tools and determine where it should hop to at each step.

We know we're being quite ambitious here, but we think there's a lot we can improve on over existing solutions.

Thanks again :)

Post reply on HN