Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • when will the graph memory layer be available?
  • We plan on launching end of month.
  • How does this compare vs. Turbopuffer?
  • We see comparable results for vectors and FTS.

    For vector search we have warm and cold p99s of approx 20ms and 400ms respectively. For FTS, warm and cold query p99s of approx 15ms and 250ms respectively.

    Both of these benchmarks were run on 1m docs.

  • does it support fts/vector on edges of the graph?
  • Yes you can put vectors, full text data, secondary and range indexes on both nodes and edges.
  • Are you ACID? And does this version have multi-tenancy?
  • Congrats on the launch George!

    Looking forward to looking into the generalised AI memory layer when it comes out.

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

  • Where's the source code for the database itself? Looks like the repo is just a client.

    Congrats on the launch!

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

  • Currently #5 on gdb-engines.com - definitely worth a look.
    by cjlm
  • yooo this is awesome. Didn't even realise :)
  • How rankings are calculated? HelixDB has zero feature scores, unlike e.g. JanusGraph which is at #27 or Neo4j at #1.
    by dig1
  • congrats on the launch! site and docs look great.

    can you host this yourself or do you need to use helix-cloud? the chat thing on the side seems to push me to helix-cloud but it looks like that starts at like $600/mo which is above my experimentation budget.

    looking for a db for an agent memory application and i'd probably start with something that's just self-hosted / freeish. postgres is working ok but I want to start ingesting server and chat logs.

  • You can definitely host it for free locally for now.

    We aim to launch our GA cloud at the end of this month, which will be much more affordable.

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

  • We've been having some issues with intermittent performance on multi hop queries.

    What's your p99 like for multi hops?

  • If your use case is OLAP based, please check it out PuppyGraph. It’s a graph query engine that sits on top of your Lakehouse (no ETL required). Our benchmark has shown consistently that 10-hop queries across billions of edges in <2 seconds. Our customers including some most data demanding companies like Coinbase, Datadog, Palo Alto Network, Netskope, AMD, etc.
    by zw17
  • In prod we see p99’s of <10ms ms for warm queries and around 50ms per hop for cold queries.
  • I've been working on a graph database in Rust this year actually! I'd love to hear anything you can talk about wrt the query planner and/or how you decided to do cardinality estimation. I decided to go with an EAV graph which makes CE pretty complex, and it's been an interesting challenge to balance quality and speed and expressiveness in the query language