Launched this week
HelixDB
An open-source OLTP graph-vector database built in Rust.
96 followers
An open-source OLTP graph-vector database built in Rust.
96 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.
Agents walking a graph through MCP instead of generating queries is a better primitive than most RAG stacks offer. HelixDB combining vector search and graph traversals in one engine skips the sync layer between your vector store and graph DB... that glue code is where production pipelines break. HelixQL being type-safe matters more than it sounds. When an agent autonomously queries data, a runtime type error hits harder than in a human-driven flow. Worth watching whether the custom query language creates friction for teams on Cypher. A compatibility layer there would ease adoption.
Autumn
Love the helix DB team and product. Congrats!
HelixDB
@ay_ush Cheers mate