Launched this week
HelixDB
An open-source OLTP graph-vector database built in Rust.
94 followers
An open-source OLTP graph-vector database built in Rust.
94 followers
After more than a year of development, HelixDB is now generally available! Whether you're an indie hacker building custom agent memory, or a Fortune 500 that needs an infinitely scalable and highly available OLTP graph/vector database, we can handle your workload. Star the repo! https://github.com/HelixDB/helix-db
HelixDB
@georgecurtiss Congrats on the launch George. This almost has its own query language, HelixQL. What influenced its design, and how does it compare to SQL, Cypher, or Gremlin?
HelixDB
@kimberly_ross We took influence from Gremlin's functional approach, which we prefer over Cypher, some design choices from SQL, and some syntax choices from Rust.
Product Hunt
HelixDB
@curiouskitty we're avoiding OLAP use cases, as there is already a market for this and companies doing it very well. The problem we're solving; is for people that need a fast, scalable transactional graph/vector database. The specific use cases within that can go quite broad. :)
Really impressive journey especially scaling to billions of queries
Curious — with this kind of workload, how are you handling security around data access and isolation?
Especially if teams are using it in multi-tenant or production environments
HelixDB
@shrujal_mandawkar1 Our compiled queries offer a level of security, that allows the developer to define the ways in which data can be accessed. For our cloud, we have auth built-in, but any user specific access controls has to be implemented by the developer.
@georgecurtiss Makes sense — giving developers control at the query level is definitely powerful.
We’ve seen in a few cases though, even with strong query controls, issues like IDOR or improper access validation can still slip in when apps scale or multiple services interact.
Especially in multi-tenant setups, small gaps in authorization logic can expose cross-tenant data unintentionally.
Are you planning to introduce any built-in guardrails or audit mechanisms on top of this?
HelixDB
@shrujal_mandawkar1 No. It's very hard to make a generalised system that will be concrete for all our customers.
@georgecurtiss Yeah that’s fair makes sense not to enforce a one-size-fits-all approach
We’ve seen though that when access control is fully left to developers, things like IDOR or cross-tenant leaks can creep in over time — especially as systems grow
That’s usually where external testing helps catch those gaps early before they become real issues
Graph + vector + OLTP in one engine is interesting. Are you targeting agent memory use cases primarily, or positioning this as a general-purpose database long term?
HelixDB
@mithlesh_shah agent memory is definitely a wedge right now, but there's no reason why you cant use us for any graph or vector use-case :)
@georgecurtiss Makes sense - agent memory is a strong entry point right now. Expanding into broader graph/vector use cases over time feels like a smart path.
Autumn
Love the helix DB team and product. Congrats!
HelixDB
@ay_ush Cheers mate
Graph + vector in a single engine built in Rust is exactly what the agent ecosystem needs right now. Most people are duct-taping Postgres + Pinecone together — having native support for both traversal and similarity search in one place should make agentic workflows way cleaner. Excited to see what the HelixQL language evolves into.