HelixDB: a graph-vector database that ships its own query DSL
HelixDB is an OLTP graph database with native vector and full-text search built in Rust on Object Storage.
At a glance
- What is it?
- HelixDB combines graph traversal, vector search and full-text search behind one HTTP endpoint, with SDKs in Rust, TypeScript, Python and Go. The interesting part is not the storage claim but the query model: queries are built as an AST in your application language and posted to a running instance with no compile or deploy step.
- Who is it for?
- Adopt HelixDB if you are building retrieval over connected data and want graph traversal and vector search in one process rather than a graph store plus a separate vector index. Do not adopt it if you need a stable wire format you can hand-write, or if your team is unwilling to track four SDKs whose published versions are not aligned.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is retrieval over connected data, not storage
The README opens with a list of things it wants you to stop running separately: an application DB, a relational DB, a vector DB, a graph DB, and the glue layers that keep them consistent. That is the actual pitch. If you are building retrieval over documents that reference each other, the usual shape is a vector index for similarity and a relational or graph store for the relationships, with your application code joining the two result sets. HelixDB's claim is that one engine answers both. The stated audience is AI applications: the README names memory, company brains, and federated access to company data for agents. Graph plus vector is described as the primary data model, with KV, documents and relational data as secondary support. That ordering matters when you evaluate it. This is a graph database that grew vector search, not a vector database with a graph bolted on.
Queries are built as an AST in your language and posted as JSON
The mechanism is worth understanding before the install steps, because it shapes everything else. You do not write a query string. In Rust you annotate a function with #[query] and return a WriteBatch or ReadBatch built from a g() traversal object. In TypeScript you call writeBatch(), varAs(), addN(), project(), and the package exports Predicate, PropertyInput, PropertyProjection, defineParams, param, g, readBatch and writeBatch. The README states plainly that the SDKs produce the same JSON AST and that it is sent to a running instance through POST /v2/query with no build or deploy step. So the SDK is a client-side query builder, not an ORM and not a server-side function registry. A consequence the README does not spell out: the server is a query executor over a wire format, and the DSL surface lives in four separate packages. The Rust example uses .value_map(None::<Vec<String>>) while the TypeScript example uses .project([PropertyProjection.new("name")]), which are close but not identical shapes. Reading the two side by side is the fastest way to see how much of the builder API is genuinely shared and how much is per-language ergonomics.
Getting a local instance running: two paths, one of them interactive
Installation is a shell script on macOS and Linux: curl -sSL "https://install.helix-db.com" | bash. Windows uses a PowerShell one-liner that pulls install.ps1 from the main branch of the repository. helix update moves an existing install forward. From there the README offers a fast path and a manual path. The fast path is helix chef, described as an interactive one-shot bootstrapper that installs query skills and a docs MCP, scaffolds a project, starts a local instance, seeds example data, and writes HELIX_CHEF_PROMPT.md. It detects agents in a fixed order: Claude Code, then OpenAI Codex, then OpenCode, then Cursor Agent. The manual path points at the canonical quickstart in the docs rather than reproducing it, which is a reasonable choice but means the README alone will not get you to a running dev instance. What the README does pin down is the default port: helix start dev serves on http://localhost:6969, and the SDK examples target that address. The Rust client defaults there with Client::new(None). The TypeScript example hardcodes it as http://localhost:6969/v2/query. If you are evaluating HelixDB without an agent installed, helix chef will scaffold and seed but has nothing to hand off to, so plan on the manual quickstart instead.
Four SDKs, four version numbers, and that is the real cost
The README's own table is the most useful part of the document for anyone doing due diligence. Rust is published as helix-db 3.0.0. TypeScript is @helix-db/helix-db 3.0.4 on npm and requires Node.js 20+. Python is helix-db 0.3.4 on PyPI. Go is github.com/helixdb/helix-db/sdks/go at v0.3.1. The server itself is at v3.1.1. Those numbers do not move together, and the README does not explain the versioning scheme or promise compatibility between a client and a server release. The Rust crate is imported as helix_db while published as helix-db, a small detail that will cost someone ten minutes. The practical reading is that the Rust SDK is the reference implementation and the others trail it. If your stack is Python or Go, the question to answer before you write code is whether the builder catalog in your language matches the one in the Querying Guide, because the README only shows Rust and TypeScript examples in full. The Python and Go sections are links to setup guides, not worked examples.
Where the model creates friction
The no-build-step design is genuinely convenient for iteration and genuinely awkward for operations. Because queries are constructed in application code and serialized to JSON, the query logic lives in your service, not in the database. That is fine until you want to inspect what was actually executed, pin a query's behaviour across a client upgrade, or reuse the same traversal from a service in a different language. You can read the JSON AST, but you are reading generated output, not source you maintain. A second limitation follows from the version spread: a server upgrade to v3.1.1 alongside a Python SDK pinned at 0.3.4 is an untested combination as far as the supplied material goes, and nothing in the README states a compatibility policy. Third, the project description says the database is built on Object Storage. The README does not discuss latency characteristics, local caching, or what happens to read paths when the object store is slow or unavailable. For an OLTP system that is the first thing I would want documented and it is not in the material I have.
Compared with assembling a graph store and a vector index
The obvious alternative is running a general graph database for traversal and a dedicated vector index for similarity, then joining results in your application. That approach has a real advantage HelixDB is arguing against: each component is independently replaceable and independently documented, and you can swap the vector index without touching the graph. The cost is the join. You retrieve candidate node ids from the vector index, then re-query the graph for each one, and you own the consistency question when a node is deleted from one store and not the other. HelixDB collapses that into a single query, which is the whole reason someone would accept a younger project. The trade is that you now depend on one engine for both access patterns, and the escape hatch is not a drop-in replacement for either half. If your retrieval workload is pure nearest-neighbour search over flat documents with no relationships, the graph half is dead weight and a dedicated vector index is the simpler choice. HelixDB earns its place when the traversal is load-bearing.
Licence and maintenance posture
HelixDB is Apache-2.0, which permits commercial use, modification and redistribution with the usual attribution and notice requirements. Nothing here is legal advice; if you are embedding it in a product, read the licence text and your own obligations. On maintenance, the repository is not archived, the last push is dated 2026-09-09, and the release cadence visible in the supplied material shows v3.0.8 in July 2026, v3.1.0 in August, and v3.1.1 later in August. That is a project shipping on a roughly monthly minor cadence, which cuts both ways: fixes arrive, and so do breaking changes. The jump from 3.0.x to 3.1.x within weeks, combined with SDK versions that already disagree by major number across languages, suggests you should pin both client and server versions and read the changelog before upgrading either. The README links a changelog under docs.helix-db.com/change-log/helixdb; treat that as required reading, not optional, because the supplied material gives no other compatibility guidance.
Editorial conclusion
Adopt HelixDB if you are building retrieval over connected data and want graph traversal and vector search in one process rather than a graph store plus a separate vector index. Do not adopt it if you need a stable wire format you can hand-write, or if your team is unwilling to track four SDKs whose published versions are not aligned. Before committing, verify two things yourself: whether the Python SDK at 0.3.4 and the Go SDK at v0.3.1 expose the same builder surface as the Rust crate at 3.0.0, and whether your deployment can tolerate the Object Storage dependency implied by the project description.
Community notes