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

Show HN: HelixDB – A graph database built on object storage

github.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Show HN: HelixDB – A graph database built on object storage

#42

Post by GeorgeCurtis »

let_rec wrote: post #41

This seems like a great idea. What reassurance can you offer devs that are hesitant to try a new data-store?

Can't imagine why they'd be hesitant, Helix is awesome, we've never had any data loss issues, and are completely ACID.

I'd encourage them to start a local instance with claude/codex to build a mini project and see what it's like.

Re: Show HN: HelixDB – A graph database built on object storage

#43

Post by GeorgeCurtis »

jauntywundrkind wrote: post #18
GeorgeCurtis wrote: post #11

Earlier quoted context omitted.

PuppyGraph is a good fit for OLAP for sure. We’re just two young founders sharing what we’ve been building, so I’ll take the drive-by competitor plug as a compliment :) Definitely a different focus though. Helix is OLTP, built for operational graph + vector workloads, especially apps/agent memory where low-latency traversals and writes are concerned.

And is open source.

puppy graph is not open source

Re: Show HN: HelixDB – A graph database built on object storage

#44

Post by GeorgeCurtis »

tao_oat wrote: post #40
GeorgeCurtis wrote: post #26

Earlier quoted context omitted.

This was a TEMPORARY decision we made, and I wrote a bit about why we did this here: https://x.com/georgecurtiss/status/2060043184059912470 We’re 100% committed to going back to open-source on an Apache 2.0 license as soon as possible. In the meantime, you can continue to deploy us completely for free, however you like, using the compiled docker container.

Unfortunately it's not possible to read this without an X account.

[flagged]

Re: Show HN: HelixDB – A graph database built on object storage

#45

Post by GeorgeCurtis »

thedreammachine wrote: post #35

What kinds of graph shapes or query patterns do you feel are the worst case for object storage?

OLAP queries, deep multi-hops where latency is a priority.

As long as the sub-graph you're trying to hop is cached, then there's no problem or latency issues. However, if you need to do a deep hop query, where all those nodes and edges are in cold storage, each hop costs ~50ms. So a 10-hop would take ~0.5 seconds.

Again though, we find most people are using us for agentic workloads, so even this worst case scenario the LLMs make up the majority of the latency.

Re: Show HN: HelixDB – A graph database built on object storage

#46

Post by Bnjoroge »

GeorgeCurtis wrote: post #21
Bnjoroge wrote: post #15

congrats! how does this compare to turbopuffer, surreal or other multi-model ones built on object storage or not

tpuffer is a vector/fts database. Surreal is a bit of an "everything database". We're a graph database with vector and FTS capabilities. Our vector and FTS benchmarks are comparable with tpuffer, but you would primarily use us for building whole applications, knowledge graphs, or AI memory/retrieval. Anything that is relationship intense. Let me know if this properly answers your question

it does, think I misunderstood your value prop. best of luck -definitely a real usecase.

Re: Show HN: HelixDB – A graph database built on object storage

#47

Post by aitchnyu »

GeorgeCurtis wrote: post #42
let_rec wrote: post #41

This seems like a great idea. What reassurance can you offer devs that are hesitant to try a new data-store?

Can't imagine why they'd be hesitant, Helix is awesome, we've never had any data loss issues, and are completely ACID. I'd encourage them to start a local instance with claude/codex to build a mini project and see what it's like.

Does it work only on S3?
Post reply on HN