HelixDB v3 puts graph, vector, and text queries in one store
HelixDB v3 is built for applications that would otherwise split connected data, embeddings, text search, and ordinary records across several systems. The core model is graph plus vector, with key-value, document, and relational data also described in the README. An agent memory service is the obvious example: relationships answer who or what is connected, vector search finds similar material, and full-text search handles exact language. Keeping those operations together can remove synchronization code between databases.
That convenience comes with a new query surface. Rust, TypeScript, Python, and Go SDKs all produce the same JSON abstract syntax tree and send it to POST /v2/query. The current examples build read and write batches through Helix's own typed functions. This is pleasant if your team wants compiler help, but it does not preserve an existing SQL or Cypher integration. Choosing HelixDB means choosing its SDK and wire format along with its storage engine.
Four SDKs make the client story broader than the server story
The README lists four released SDKs: Rust 3.0.0, TypeScript 3.0.4, Python 0.3.4, and Go v0.3.1. Each has a complete setup example, and each talks to the same local default on port 6969. The version labels need attention because HelixDB v3, Helix CLI 3.x, and the /v2/query path describe different layers. The documentation calls that distinction out directly, which should prevent a fair amount of version confusion.
helix chef is the fastest guided start. It installs query Skills and the docs MCP, creates a project, starts a local instance, seeds sample data, and can hand work to Claude Code, Codex, OpenCode, or Cursor Agent. Manual setup is also documented for developers who want to see every file. Cloud adds a WorkOS login plus workspace, project, and tenant selection. Application keys are displayed once for direct gateway clients and are separate from the CLI's brokered access.
What happened when we ran it
Our sandbox installed 578 Rust packages in 28 seconds. The build completed successfully in 412 seconds, a little under 7 minutes. That is a meaningful wait for a clean development container, though it is unsurprising for a Rust database of this size. The checkout contained 1,941 files, about 513,445 lines of source, and occupied 26.7 MB before the dependency work began.
Testing is the more important result. cargo test had reported 1,844 passed and 0 failed tests when our 900-second cap stopped the command. The last logged cases were vector DDL, magnitude validation, tenant partition, atomic update, lifecycle, and reference-model checks, all marked ok. Zero recorded failures is encouraging. The command still did not complete, so it cannot be called a passing test run, and a normal CI budget must account for the unfinished tail.
Our repository scan also found 13 CI workflow files and a Dockerfile. There was no top-level tests directory, but the 1,844 completed cargo cases show that absence is not evidence of missing tests in a Rust workspace. The useful operational finding is timing: installation and build consumed 440 seconds together, while the full test process outlived a further 900 seconds on 3 CPUs and 12 GB of RAM.
One writer and object storage define the Cloud tradeoff
HelixDB Cloud uses object storage, full ACID transactions, at least 3 gateways and database nodes, one writer, and auto-scaling readers. That topology can suit read-heavy retrieval systems, but it puts a clear boundary around write scaling. A team evaluating Cloud should test its actual mix of graph mutations, vector updates, full-text indexing, and reads instead of treating a unified API as proof that every part scales the same way.
Open issue #1101 gives that test a specific target. Its reporter measured about 330 GetObject requests per second on an idle v0.0.5 instance, reading roughly 164 GB over 15 hours from a 931 MB database. The report attributes the traffic to repeated vector-memory hydration and says the same loop remained in v3.2.0. Release v3.3.0 does not list that issue among its changes. Because the report predates the v0.0.6 Docker image, verify the current image rather than assuming either that it is fixed or that it still reproduces.
v3.3.0 is active, while deletion needs a regression test
GitHub recorded 5,960 stars, 23 open issues and pull requests, and a push on September 20, 2026. Release v3.3.0 arrived that day with query, SDK, CLI, Docker, vector, and managed-database fixes. The open queue had 7 issues and 16 pull requests when fetched. That combination points to active maintenance and active change, which is exactly what a database buyer should expect to test carefully.
Issue #1109 reports that edge-stream .drop() on server v0.0.5 with TypeScript SDK 3.1.0 returned HTTP 200 but removed no edge. The reporter found about 28,000 stale edges and 25,000 duplicate pairs before an export exposed the problem; dropEdgeById worked in the reproduction. A fix was already open as pull request #1114 on September 20. Until your chosen server and SDK versions include and verify it, keep a count-based deletion regression in the adoption suite.