Live data from Hacker News

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

github.com

111–117 of 117 posts

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

#111

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…

> You can see the results and links to our code in the write-up here: https://surrealdb.com/blog/beginning-our-benchmarking-journe...

page says your benchmark runs on 5M of records only. Is it incredibly small dataset in current world, and is it more micro-benchmarking?

Also, count(*) query having 5s latency on 5m records is very underwhelming if I understand your tables correctly.

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

#112
post #2

Looks nice! Are you looking to compete with https://www.falkordb.com or do something a bit different?

Pretty much, our biggest focus is on Graph and Hybrid RAG. They seem to have really honed in on Graph RAG since the last time I checked their website. One of the problems I know people experience with them is that they're super slow at bulk reading. Oh also, they aren't built in Rust haha

[dead]

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

#113
post #79

Earlier quoted context omitted.

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 GraphD…

Looking at your benchmarks you say for inserting 1k edges its around 500,000 ns/iteration. Is this 500,000 ns/per edge insertion or for all 1k of them?

Hello. These benchmarks are a bit outdated, we’re currently updating them this sprint.

The open-source in-memory version loads around 3 million edges/second, while the on-disk version handles does about 2 million edges/second with a WAL batch size of 100, and 3m with no WAL.

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

#114

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

What are MuskMap and TrumpMap (I'm kind of afraid to ask), and can you link to more info about how they used your database?

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

#115
post #79
post #50

Looks 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 GraphD…

When are you planning on releasing your commercial version? I couldn't find any information online with regard to pricing, etc.

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

#116

Earlier quoted context omitted.

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.

What are MuskMap and TrumpMap (I'm kind of afraid to ask), and can you link to more info about how they used your database?

They were two viral web apps that blew up on twitter. They had approx 25,000 users at their peak.

Originally they were built on Postgres, so we helped move over to us. Their graph had about 50,000 user nodes and 25 million edges (follower connections). This then made it a lot more optimised to handle the highly interconnected users to find shortest paths between one user and Elon Must / Donald Trump.

So to sum it up, they stored clones of all the users and how they were interconnected by follower relationships, and then used our query language to super easily calculate the shortest paths.

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

#117
post #99

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…

Neo4j performance is horrendous unless you have huge amounts of memory. I would wager that anyone who has used Neo4j for anything related to graphrag or used its vector features knows it’s not a great solution. Anyone can verify this quite easily.
Post reply on HN