HydraDB makes object storage the durable graph layer
HydraDB puts graph records, write-ahead logs, manifests, and traversal indexes in S3-compatible storage. Query nodes keep replaceable local caches and serve reads or canonical mutations. Separate indexers build immutable traversal structures in the background. That division is the project's reason to exist: a node can disappear without taking the durable graph with it, and query capacity can scale separately from index construction.
This architecture is more specific than a claim of being a fast graph database. Reads pin one SlateDB snapshot, and indexed traversal combines that compiled base with the visible write-ahead-log tail. Object-store leases select an active writer for each cell. Clients connect over Bolt 5.x or HTTP, while strong reads explicitly refresh from object storage before the query snapshot is pinned. Those choices make sense for a team already designing around replaceable compute and durable buckets.
What happened when we ran it
Our sandbox cloned commit 6a2fbb1 and installed 309 Rust packages in 42 seconds. The normal build completed successfully in 249 seconds. The checkout was 4.3 MB, with 156 files and about 106,143 lines of source. We found 2 CI workflow files, a Dockerfile, and no top-level tests directory. The successful build is meaningful because this project crosses Rust, C, storage, networking, and sparse-matrix code.
Tests ran for 133 seconds and ended with exit code 101. The final linker invocation for the slatedb-graph-kernel test library could not find -lgraphblas, after which Cargo stopped with one compilation error. HydraDB's README names SuiteSparse GraphBLAS as a source prerequisite. The log proves the library was unavailable to that link step; it does not prove that installing it would make every test pass.
Source development needs two native graph libraries
The documented source route requires Rust 1.91 or newer, a C/C++ toolchain, libcypher-parser, SuiteSparse GraphBLAS, and just. Ubuntu users get explicit package names. macOS users need a separate Homebrew tap for the Cypher parser and environment paths when invoking Cargo directly. The guide also explains why the official Rust installer is preferred over Homebrew's current keg-only rustup formula.
Running a node adds configuration that a successful compile cannot check. The local recipe creates store and cache directories, writes an authentication token, names the graph, cell, and node, binds Bolt and HTTP addresses, and sets RUST_MIN_STACK to 33554432. The README warns that without that stack setting a node can answer readiness and then abort on its first query. Its verification therefore performs a write and reads the result back instead of trusting an open port.
The container route removes compilation, not database operations
The published image includes graph-node and graph-indexer, with current tags intended for amd64 and arm64. A local container can use host directories as its object store and cache. The documented command runs as the host UID and GID because the image's default user may not be able to write a bind mount. That is a precise setup warning, and exactly the kind that keeps a first storage operation from looking like a database defect.
A production cluster still needs object-store credentials, TLS certificates, authentication, advertised Bolt addresses, local cache volumes, and separate resource choices for query nodes and indexers. The Helm chart covers services, network policies, disruption budgets, and optional Prometheus integration. HydraDB centralizes those pieces around its architecture, but it does not turn a distributed database into a one-container production deployment.
OpenCypher support is useful and deliberately incomplete
The README describes support for typed relationships, bounded variable-length paths, predicates, ordering, pagination, aggregation, OPTIONAL MATCH, UNION, and batched UNWIND writes. It also exposes snapshot-scoped path procedures that can evaluate several source and target values together. Neo4j drivers can use routed URIs, which lowers the client-side cost of an evaluation.
The word subset matters. Open issue 216 requests numeric functions such as abs, ceil, and round. Issue 196 reports that an evaluator using the latest Docker image could read through the local HTTP endpoint but received errors during create and delete attempts. That issue is a report, not our reproduced result, yet it is serious enough that a trial should begin with the exact mutation cycle the application needs.
Current issues show interest, while v0.1.1 remains early
The repository's last code push was August 19, 2026, and its newest tag is v0.1.1 from August. GitHub listed 4,098 stars and 146 combined issues and pull requests when fetched. Issues were still being opened and updated on September 21, including query functions and mappings that currently turn distinct storage or traversal errors into generic server failures. That is active scrutiny, but recent issue creation is not the same as a recent fix.
Open issue 67 also says the current read path materializes a full result before paging it. We are not repeating the performance estimates in that report because our lab did not run a query benchmark. The actionable fact is narrower: teams expecting large paged results should inspect the execution path and reproduce it with their own graph before choosing HydraDB for that workload.
Adopt the architecture only when you need the architecture
HydraDB is most convincing as a focused systems project: durable graph state in object storage, disposable compute, separate indexers, snapshot reads, and familiar client protocols. Its documentation is unusually candid about native packages, stack size, bind-mount ownership, and the difference between readiness and a real write. That makes it possible to evaluate without pretending the setup is smaller than it is.
The v0.1.1 tag and open query-path questions keep it in trial territory for most teams. If S3-native graph durability is central, the 249-second successful build is a reasonable invitation to continue after installing the documented native libraries. If the architecture is merely interesting, an established graph server or a PostgreSQL extension will leave fewer new failure modes for your team to own.