HelixDB: a Rust graph-vector database for knowledge graphs and AI memory

The problem HelixDB targets: one store for linked entities and embeddings

Most retrieval stacks for AI applications end up with at least two databases. A relational or document store holds the entities and their relationships. A vector index holds the embeddings. A search engine, if there is one, holds the text. Keeping those in sync is application work, and it is work that breaks quietly: an entity is deleted in one place and its embedding lingers in another.

HelixDB's premise is that a knowledge graph and its embeddings belong in the same record. The README states the project operates primarily with a graph plus vector data model, and that it also supports KV, documents and relational data. The stated audience is AI applications: agents that need federated access to company data, memory layers, and what the README calls company brains.

That framing matters because it changes what the query language has to do. If you only need nearest-neighbour lookup over a flat corpus, a dedicated vector database is simpler. HelixDB is aimed at the case where a retrieval step starts from an entity, walks its edges, and then ranks the reachable nodes by embedding similarity. The README's own example is a User node with a name property, which is a small illustration of a larger claim: nodes and edges are first-class, not a metadata column on a vector row.

How the query DSL becomes a JSON AST and reaches the server

The mechanism is worth understanding before you install anything, because it determines what you can debug.

Queries are authored in a DSL available for Rust, TypeScript, Go and Python. According to the README, the SDKs produce the same JSON AST, and that AST is sent to a running instance through POST /v2/query. There is no build or deploy step: the query is constructed in your application process and posted to the server, which plans and executes it. The README points to a planner crate and an ast crate in the workspace, and the Cargo.toml confirms both exist alongside server, db, graph-algorithms and value-semantics crates.

The practical consequence is that your query is data, not a compiled artifact. You can log the JSON, replay it with curl, and diff two versions of a query without rebuilding a server. The cost is that validation happens at the server boundary rather than at compile time, except in Rust where the #[query] attribute macro gives you typed helpers. In TypeScript the README shows defineParams with param.string() and Predicate.eqParam, which moves some of that checking into the SDK but not into the type system's full strength.

The Rust example in the README is the clearest statement of the shape: write_batch() and read_batch() are the two entry points, g() starts a traversal, add_n creates a node with a label and properties, n_with_label plus where_ filters, and value_map projects properties. Both return types are explicit, WriteBatch and ReadBatch, which is a design choice that keeps read and write paths separate rather than pretending they are one API.

Installing the Helix CLI and running a first query against a dev instance

The README gives two installation paths. On macOS and Linux the CLI installs from a shell script. On Windows PowerShell it installs from a script in the repository. The CLI manages local instances and talks to Helix Cloud.

curl -sSL "https://install.helix-db.com" | bash

After installation, the README says helix update moves you to the latest version. The README also describes helix chef, an interactive bootstrapper that installs query skills and docs MCP, scaffolds a project, starts a local instance, seeds example data, and writes a HELIX_CHEF_PROMPT.md file. It detects supported agents in a fixed order: Claude Code, then OpenAI Codex, then OpenCode, then Cursor Agent.

helix chef

The README states it takes no flags; you answer what you want to build and follow the prompts.

If you prefer to wire things up yourself, the README points to a canonical local quickstart in the docs rather than reproducing the steps, and notes that the quickstart uses the exact files and dev instance generated by the current CLI. The default dev port is 6969, which the README states explicitly when describing the SDK examples.

For a Rust project, the crate is published as helix-db and imported as helix_db. The README's install line is:

cargo init && cargo add [email protected] tokio sonic-rs

The client defaults to http://localhost:6969 when constructed with Client::new(None). A minimal query defined with the #[query] macro returns a Result<QueryRequest, QueryError>, which you pass to client.query(...).send().await. The README's example defines add_user and get_user, then prints the JSON response with sonic_rs::to_string_pretty. What you should see is a JSON value containing the projected properties of the node you just wrote, then the same node read back by name.

Running the server from the Dockerfile and what the image actually pins

The repository ships a Dockerfile, which is the path for anyone who wants the server without the CLI. It is a two-stage build: a Rust 1.97.1 bookworm builder image compiles the server binary with cargo build --locked --release --package server --bin server, and the runtime stage is gcr.io/distroless/cc-debian12:nonroot.

The build stage does something unusual and worth noting: after building, it runs readelf on the binary and greps for a glibc loader path, then asserts the binary does not link musl. That is a guard against accidentally shipping a binary that will not run on the distroless glibc base. It is a small detail, but it tells you the maintainers have been bitten by a mismatched target before.

The runtime image sets HELIX_HTTP_ADDR to 0.0.0.0:8080, HELIX_GRPC_ADDR to 127.0.0.1:8081, DB_PATH to db/, and RUST_LOG to server=info,db=info,slatedb=info. It exposes port 8080, runs as user 65532, and sets STOPSIGNAL SIGTERM. The entrypoint is /bin/helix-server.

Two things stand out. First, the gRPC address binds to loopback while HTTP binds to all interfaces, so anything reaching the container over the network goes through the HTTP path. Second, the RUST_LOG default names slatedb, which is the storage layer the server logs under. The Dockerfile does not describe replication, clustering or a persistent volume, so if you run this image you are responsible for mounting something at the working directory the server writes to, and the Dockerfile does not document that.

The image label records the license as Apache-2.0, matching the repository LICENSE.

Where HelixDB is the wrong choice, and how it differs from Neo4j

The honest limitation is operational maturity, and it is visible in what the README does not say. There is no section on backup, restore, point-in-time recovery or rollback. There is no discussion of replication or failover. The Dockerfile describes a single-process server. For a project at version 3.1.1 with a release cadence of roughly monthly patches in mid-2026, that is not surprising, but it means HelixDB is not a drop-in replacement for a database your compliance team already trusts.

The second limitation is version skew across SDKs. The README's own table lists Rust at 3.0.0, TypeScript at 3.0.4, Python at 0.3.4 and Go at v0.3.1. Those are not the same generation of API. The Python and Go packages carry a 0.x version while Rust and TypeScript carry 3.x. If you plan to write queries from a Python service and a Rust service against the same instance, verify that both SDKs emit the AST the server expects before you design around it.

The comparison with Neo4j is the one people will make. Neo4j is a mature property graph database with its own query language and a long operational history. HelixDB's difference is that vector and full-text search are native to the same engine and the same query, rather than bolted on through a separate index or a plugin. The README's claim is that you do not need a separate application DB, relational DB, vector DB or graph DB. If your workload is pure traversal over a stable, well-understood schema, Neo4j's maturity is the better trade. If your workload is retrieval over entities where the ranking step is embedding similarity, HelixDB collapses two systems into one, and that is the reason to accept the younger operational story. The README does not publish a benchmark against Neo4j, so do not assume a performance advantage in either direction.

Maintenance cadence, upgrade cost and the Apache-2.0 licence

The last push to the repository was on 2026-09-09, and the most recent release listed is v3.1.1 from 2026-08-16, following v3.1.0 on 2026-08-08 and v3.0.8 on 2026-07-05. That is a patch-heavy cadence with occasional minor bumps, which suggests the project is still moving quickly enough that pinning versions matters.

The upgrade cost is concentrated in the SDK boundary. Because queries are JSON ASTs sent to POST /v2/query, a server upgrade can change what the server accepts even when your application code is unchanged. The README's install examples pin explicit versions ([email protected], @helix-db/[email protected]), and that is the habit to keep. The CLI has its own update path through helix update, which the README mentions, so a local instance and the CLI that manages it can drift apart independently of your application dependencies.

On licensing: the repository is Apache-2.0, and the Dockerfile labels the image with the same identifier. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, which is friendlier than a bare MIT for a database you might embed. It also requires you to preserve notices and state changes. This is not legal advice; if you are redistributing a modified HelixDB, have counsel read the LICENSE file rather than this paragraph.

Editorial conclusion

Adopt HelixDB if you are building retrieval over linked entities and want traversal, vectors and text in one store rather than three. Do not adopt it if you need a mature operational story: the README does not document backup, restore or rollback, and the Dockerfile pins a single-process server with no replication described. Before committing, run helix start dev on port 6969, send one query through POST /v2/query, and confirm the response shape matches what your SDK version expects.

Frequently asked questions

Official sources

1. HelixDB/helix-db on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases