helix db - Moses Yebei

The Problem

Building AI applications typically requires stitching together separate databases—relational, vector, and graph—each with its own query language, operational model, and data duplication. HelixDB addresses this by unifying these data models into a single storage engine, reducing the operational complexity of managing multiple systems for knowledge graphs, AI memory, and application data.

What This Does

HelixDB is a graph-vector database built from scratch in Rust, designed to serve as a unified platform for AI applications. It supports graph, vector, KV, document, and relational data models within one engine. The repository includes a CLI (crates/cli/src/main.rs), SDKs for Rust, TypeScript, Python, and Go (sdks/), and a query AST shared across all clients (crates/ast/src/lib.rs).

The project provides a helix chef command that bootstraps a full application—scaffolding, local instance, seed data, and optional handoff to coding agents like Claude Code or Codex. The core storage layer runs on object storage (S3-compatible), with an in-memory mode for development.

How It Is Wired

This is a collection of six self-contained projects, not a single codebase. The main components are:

crates/ (1532 files): Core database engine, planner, and CLI
sdks/ (76 files): TypeScript, Python, Go client libraries
bindings/ (18 files): UniFFI bindings for cross-language support
tools/, scripts/, docker-image/: Supporting utilities and containerization

The CLI entry point is crates/cli/src/main.rs, which routes to helix init, helix start, and helix query commands. Queries are authored as DSLs in each SDK, serialized to a shared JSON AST, and sent to a running instance via POST /v2/query. The Python SDK (sdks/python/src/helixdb/client.py) shows a circular import cycle with helixdb/__init__ and async_client, making changes to those modules riskier.

The TypeScript SDK (sdks/typescript/src/index) is the most-connected module (10 importers), meaning changes there have the widest blast radius across SDK consumers.

How To Use It

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

# Quick start
helix chef

# Manual setup
helix init
helix start dev
helix query dev --file examples/request.json
helix stop dev

Default storage is in-memory (data wiped on stop). Use --disk or --storage-uri s3://... for persistence. SDKs connect to http://localhost:6969 by default.

Real-World Use

A company building an AI assistant with company knowledge could use HelixDB to store employee records (relational), document embeddings (vector), and organizational relationships (graph) in one system. The assistant queries across all models in a single request, eliminating data synchronization between separate stores.

Code Health & Issues

Static analysis identified 392 findings (72 high, 320 medium) across four categories:

High - Import cycle in Python SDK: sdks/python/src/helixdb/client.py participates in circular imports with __init__ and async_client. Fix: extract shared types or defer imports.
High - Deep nesting (57 instances): crates/planner/src/planning/selected/native/scoped/control_flow/tests.rs reaches indentation depth 10. Fix: use early returns and guard clauses.
High - Duplicated code: 127 repeated 6-line blocks across 78 files in crates/db/fuzz/fuzz_targets/. Fix: extract shared helpers.
Medium - File handles without context managers: sdks/python/src/helixdb/client.py uses bare open() calls.

SDLC observations:

High - Third-party GitHub Actions pinned to tags, not commit SHAs (supply-chain risk)
Medium - No dependency update bot configured
Medium - No vulnerability scan gate in CI
Medium - persist-credentials: false not set on checkout

The Bottom Line

HelixDB is a serious, well-structured database project with real engineering depth—the Rust core, unified query AST, and multi-SDK support are substantial. It's early-stage (no stars, in-memory default) but the architecture is sound. Teams building AI applications that need unified graph+vector storage should evaluate it; those needing production stability should wait for maturity.

What the analyser found

Deployment readiness

7/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

1,805 files

Rust1487
Markdown31
JSON29
TOML24
Python21
Shell15

ReactExpressDocker

Module dependencies

The 10 most depended-upon modules of 43, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_sdks_typescript_src_index["index"] n1_escript_scripts_parity_paths["paths"] n2_ks_python_src_helixdb_client["client"] n3_dks_python_src_helixdb_graph["graph"] n4_n_src_helixdb__client_common["_client_common"] n5__python_src_helixdb___init__["__init__"] n6_hon_src_helixdb_async_client["async_client"] n7_pts_parity_generate_fixtures["generate-fixtures"] n8_sdks_typescript_src_graph["graph"] n9__scripts_parity_compare_json["compare-json"] n5__python_src_helixdb___init__ --> n6_hon_src_helixdb_async_client n5__python_src_helixdb___init__ --> n2_ks_python_src_helixdb_client n5__python_src_helixdb___init__ --> n3_dks_python_src_helixdb_graph n9__scripts_parity_compare_json --> n0_sdks_typescript_src_index n9__scripts_parity_compare_json --> n1_escript_scripts_parity_paths n2_ks_python_src_helixdb_client --> n5__python_src_helixdb___init__ n2_ks_python_src_helixdb_client --> n4_n_src_helixdb__client_common n2_ks_python_src_helixdb_client --> n3_dks_python_src_helixdb_graph n6_hon_src_helixdb_async_client --> n4_n_src_helixdb__client_common n6_hon_src_helixdb_async_client --> n2_ks_python_src_helixdb_client n0_sdks_typescript_src_index --> n8_sdks_typescript_src_graph n3_dks_python_src_helixdb_graph --> n2_ks_python_src_helixdb_client n7_pts_parity_generate_fixtures --> n0_sdks_typescript_src_index n7_pts_parity_generate_fixtures --> n1_escript_scripts_parity_paths classDef cyc stroke:#ef4444,stroke-width:2px; class n2_ks_python_src_helixdb_client,n3_dks_python_src_helixdb_graph,n5__python_src_helixdb___init__,n6_hon_src_helixdb_async_client cyc;

Dependencies

12 declared dependencies, none a major version behind. Resolved 0 of 12 against the registry.

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high1

medium3

Pin third-party GitHub Actions to a commit SHAhigh6 occurrences

.github/workflows

dtolnay/rust-toolchain@1.97.1, taiki-e/install-action@cargo-llvm-cov, Swatinem/rust-cache@v2, dtolnay/rust-toolchain@nightly

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Enable Dependabot or Renovatemedium

21 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/cli-tests.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.