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.

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

Soon you’ll be able to host it yourself AND have access to the source code

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

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.

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

email us: founders@helix-db.com

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.

You can query HelixDB using JSON or directly in your programming language of choice by using our Rust, TypeScript, Go or Python SDKs. We’ve found AI is very good at working with the SDKs and JSON itself to query, making the development experience much better than before: https://docs.helix-db.com/database/querying

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.

Why graph, vector and FTS? Graph databases provide a natural cognitive model for data, vectors allow for a semantic understanding of the entities and relationships in the graph, and FTS provides more specific filtering. Many AI-driven applications attempt to combine all of these functionalities by stitching together multiple disconnected systems, but even then there’s no native way to perform joins or queries that span all systems. You still need to handle this logic at the application level.

Helix started as a graph DB, but we moved to a hybrid graph/vector approach after attempting to build an AI memory system, which led us down the GraphRAG and HybridRAG rabbit hole, where we would need separate graph and vector databases.

We knew scalability would be a challenge at each stage of our product's development, however our initial focus this past year was to prove out the product through local deployments and was only meant to be run on a single node. Scaling graph DBs remained a difficult and expensive problem we’d have to solve later. Some common ways other graph DBs solve scaling is by duplicating entire datasets across distributed machines (extremely expensive per node), or by sharding the data.

Sharding databases is effective and affordable, however, graph data doesn’t have explicit partitions like relational databases do. For example, sharding a relational DB involves splitting up tables. When it comes to graph DBs, the edges can span across any of the partitions, and hopping across multiple machines when traversing nodes is ineffective and computationally expensive.

Replicating graph DBs for high availability and better throughput drastically increases the operational cost of the db and still has a limit of how big you can vertically scale. The workload that we’re used for requires storing a huge amount of data for agents, where only a subset of that data is ever needed at any one time. So rather than having the whole thing in memory, we can store it all in object-storage and get the bits we need when they’re needed.

Agents benefit from better context, which is achieved from more and better data (more relationships etc). By using S3 as the persistence/data layer there is no limit to how big the graph can be or how many relationships you can have, and we can scale to serve throughput and requests by horizontally spinning up nodes and caching relevant subsets of the graph on each node. This way, you get extremely low latency for “hot” data and a p99 of ~100ms for writes and ~50ms for reads from cold storage (S3). Plus you get the benefit of dirt cheap storage.

Workloads that HelixDB is currently supporting: - Huge amounts of data (TBs) from which the agents need to search and traverse over - Offering affordable graph storage for companies where cost of graph data is a bottleneck - Consolidating multiple databases, enabling AI agents to have autonomy over companies, helping them become more autonomous. - AI memory - Company brains

We’re currently working on our own generalised AI memory layer which will use HelixDB under the hood and be completely open-source. Also, we’re finishing up on pre-filtering for vector search which will allow you to pre-filter based on relationships in the graph, metadata, and sub-graphs. And lastly, GA cloud will be available in the coming weeks.

If you want to run Helix locally (either on-disk or in-memory), you can find more info on our github (https://github.com/HelixDB/helix-db) or via our docs (https://docs.helix-db.com/database/local-development). If you’re interested in getting started with our distributed cloud, please email us founders@helix-db.com.

Many thanks! Comments and feedback welcome!

Comments URL: https://news.ycombinator.com/item?id=48478148

Points: 153

# Comments: 42

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.

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 :)