HydraDB: a graph database whose only durable copy lives in object storage

The problem HydraDB targets: durable graphs without durable local disks

Most graph databases keep their authoritative copy on local disks attached to the machines running the query engine. That ties durability to those machines. Replacing a node means moving data; scaling reads means copying it. HydraDB inverts this. According to the README, "S3-compatible object storage is the durable source of truth," and both compute roles keep "only disposable state in memory and on local SSD or NVMe."

The audience is therefore narrow and specific: teams that already treat an object store as their system of record and want graph queries over it. If your data already sits in S3 and you are bolting on a graph layer, the storage model is a fit. If you want a graph library inside one process, it is not.

The README frames the benefit as compute that "can be replaced or scaled without moving the graph itself." That is the whole pitch, and it is a real one. It is also the source of every operational constraint below.

Two roles, one object store: how graph-node and graph-indexer divide the work

The architecture is a split between serving and indexing. Data nodes, the graph-node binary, "serve queries and canonical mutations." Indexers, the graph-indexer binary, "build immutable traversal indexes in the background." Both talk to the same object store and neither holds a durable local copy.

Reads are snapshot-based. The README states that "every query runs against one pinned SlateDB snapshot," and that indexed traversal "combines a compiled CSC generation with its visible WAL overlay." That second sentence is the interesting one. A CSC generation is a compressed sparse column structure, the immutable artifact an indexer publishes "through atomic object-store pointers." The WAL overlay is the tail of writes that the index has not yet absorbed. Because the reader merges the two, "readers remain correct when an index is absent or behind." An indexer that has crashed, or that is simply lagging, costs you speed rather than correctness.

Writes are serialized per cell. The README describes "object-store CAS leases" selecting "the active writer for each cell," with "SlateDB writer epochs" fencing stale writers. The cell is the unit of coordination: GRAPH_CELL_ID and GRAPH_CELLS appear in the Docker example, and the multigraph_bench example in the repository suggests more than one graph can be addressed. The README does not spell out how cells map to nodes or how many cells a single deployment should use, so that is something to settle from architecture.md before designing a topology.

Execution is graph-native rather than a translation layer: the planner uses "property indexes, reverse adjacency, sparse traversal, and SuiteSparse GraphBLAS where appropriate." Clients reach it two ways, Neo4j drivers over Bolt 5.x or the typed JSON and streaming NDJSON HTTP API.

Running a local HydraDB node with Docker and verifying it

The README offers two paths: a published Docker image, or a build from source. The image is the shorter one. It lives at ghcr.io/hydra-db/hydradb, and each v* release is tagged with its full version, compatible minor and major versions, the commit SHA, and latest.

Pull it first, and if you are on ARM, check the tag actually carries your architecture. Releases up to and including 0.1.0 were linux/amd64 only, and the README says pulling one of those on an ARM host fails with "no matching manifest for linux/arm64/v8 in the manifest list entries." That is a tag problem, not a configuration problem:

docker buildx imagetools inspect ghcr.io/hydra-db/hydradb:latest

The README's local example creates a store directory, a cache directory, and a token file before starting the container, because LOCAL_PATH must point at a directory that already exists.

mkdir -p hydradb-data/store hydradb-data/cache
printf '%s\n' 'local-development-token-32-bytes' > hydradb-data/auth-token

The run command is long, and two flags in it are load-bearing. TLS is required by default in deployed environments, so the local flow sets GRAPH_ALLOW_PLAINTEXT=true. And --user "$(id -u):$(id -g)" is required: the image runs as UID/GID 10001 while the bind mount is owned by the host user, so without it "the container cannot write its store or cache and fails on the first storage operation."

docker run --rm \
  --user "$(id -u):$(id -g)" \
  -p 7687:7687 -p 8443:8443 -p 9090:9090 \
  -v "$PWD/hydradb-data:/data" \
  -e CLOUD_PROVIDER=local \
  -e LOCAL_PATH=/data/store \
  -e GRAPH_NAMESPACE=default \
  -e GRAPH_ID=default \
  -e GRAPH_CELL_ID=cell-0 \
  -e GRAPH_CELLS=cell-0 \
  -e GRAPH_NODE_ID=node-0 \
  -e GRAPH_BOLT_NODE_ADDRESSES=node-0=127.0.0.1:7687 \
  -e GRAPH_ADVERTISED_BOLT_ADDR=127.0.0.1:7687 \
  -e GRAPH_DATA_CACHE_DIR=/data/cache \
  -e GRAPH_AUTH_TOKEN_FILE=/data/auth-token \
  -e GRAPH_ALLOW_PLAINTEXT=true \
  -e RUST_MIN_STACK=33554432 \
  ghcr.io/hydra-db/hydradb:latest

The node runs in the foreground. Port 7687 is Bolt, 8443 the HTTPS API, 9090 metrics. CLOUD_PROVIDER=local with LOCAL_PATH points the storage layer at the mounted directory instead of S3, which is what makes this a single-machine setup.

The README is explicit that a listening port proves nothing, and points to its "Verify a running node" section: "a listening port is not proof; a round-tripped write is." That verification step is not reproduced in the README excerpt available here, so treat it as the next thing to read rather than something to improvise. For source builds, the repository expects Rust 1.91 or newer, and the Dockerfile installs libcypher-parser-dev and libgraphblas-dev, so those native dependencies are not optional. The justfile exists to set the environment those builds need, including RUST_MIN_STACK=33554432, which the justfile explains is because "OpenCypher's async query futures exceed the 2 MiB default test-thread stack."

Where HydraDB is the wrong tool

The two-role split is the design, and it is also the tax. A single-node deployment still involves deciding what to do about indexing. If you run only graph-node, queries remain correct but traversal falls back to whatever the planner can do without a published CSC generation. The README does not quantify that penalty, and it would be wrong to guess at it. What it does say is that readers stay correct, which is a correctness guarantee, not a performance one.

The object store is a hard dependency in any real deployment. CLOUD_PROVIDER=local with a host directory is a development convenience, not a production topology, and the README's own production guidance points at the Helm chart and pinning an image digest rather than latest. If you have no S3-compatible storage and no intention of running one, the architecture offers you nothing over a conventional graph database.

AGPL-3.0 is the other boundary. The licence badge and LICENSE file are unambiguous, and the README does not describe a commercial exception or a hosted offering with different terms. For a database that a service links against, that is a decision for your legal team, not a footnote.

Finally, the README's own Docker example is a development node. It sets a plaintext token file, disables TLS, and binds three ports to the host. Nothing in the README describes backup, restore, or rollback procedures, and the README does not document rollback. That silence matters more for a system whose durability story rests entirely on objects you do not control.

How HydraDB differs from Neo4j and from embedded graph engines

The nearest comparison is Neo4j, and the README invites it by supporting Bolt 5.x, which means existing Neo4j drivers work unchanged. The difference is where the data lives. A Neo4j deployment keeps its store on the machines in the cluster; HydraDB keeps records, WALs, manifests, and traversal indexes in object storage and treats local disks as cache. That changes failure handling: losing a HydraDB compute node loses cache, not data, while losing a Neo4j instance loses a store you have to recover.

Against an embedded graph engine, the difference runs the other way. An embedded engine is a library in your process, with no server, no ports, no token file, and no indexer. HydraDB is a server with a query engine, a Bolt endpoint, an HTTPS API on 8443, metrics on 9090, and a background indexing tier. If your graph fits in memory and your process is the only reader, that is a great deal of machinery to adopt.

The repository also ships examples/falkor_import.rs and examples/falkor_query_bench.rs, which suggests the maintainers have looked at importing from FalkorDB. The README does not describe what that example covers in detail, so anyone migrating from FalkorDB should read the example rather than assume a supported migration path.

Maintenance, upgrades and what AGPL-3.0 means in practice

The repository is not archived, and the last push was on 2026-08-19. That is recent enough that the project is being worked on, but no releases were retrieved, so there is no changelog to read for upgrade guidance. The README does describe the image tag scheme in detail: full version, compatible minor and major, commit SHA, and latest. That scheme exists so you can pin to a minor line and take patches, or pin to a digest and move deliberately. For production the README says to pin an image digest rather than latest and points at charts/hydradb/README.md.

Upgrade cost has one structural component worth naming. Because indexers publish immutable CSC generations through atomic object-store pointers, an index format change would mean rebuilding indexes rather than migrating a store in place. The README does not state a compatibility policy for index generations, so that is a question to answer before you depend on a long-lived deployment.

On licensing: AGPL-3.0 is a strong copyleft licence with a network-use clause. The repository is the source of truth for what that means for your use, and this article is not legal advice. What can be said plainly is that the README describes no alternative licensing track, so the AGPL terms are the terms.

Editorial conclusion

Adopt HydraDB if you already run S3-compatible object storage, want graph queries without provisioning local disks for durability, and can accept AGPL-3.0. Do not adopt it if you need a single-binary embedded graph, or if you cannot operate two separate process roles. Before committing, verify the multi-architecture image tag you intend to pin, confirm the indexer role is running so traversal indexes are built, and read architecture.md for the failure semantics the README leaves out.

Frequently asked questions

Official sources

1. hydra-db/hydradb on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README