A GitHub Trending snapshot at 12:10 UTC on September 22 recorded 794 stars added in a day for HydraDB. The public main branch, meanwhile, ends on August 13. That gap makes the project worth reading closely: its Rust code describes an unusual graph database with S3-compatible storage as the durable authority, while some of the README's strongest verification links lead to missing files.
GitHub displayed about 4,100 stars and 1,200 forks when this article was reported. Those counters measure attention. They say nothing about whether a database preserves a committed write after a node fails. HydraDB provides enough public material to understand its design and run a local instance, but the path from architecture to reproducible production evidence is unfinished in the current repository.
The graph lives below the compute layer
HydraDB changes what a graph server owns. Its architecture document puts graph records, write-ahead logs, manifests, coordination records, and immutable traversal indexes in S3-compatible object storage. Query nodes keep memory and local SSD or NVMe caches that can be discarded. Separate indexer processes build compressed sparse column, or CSC, representations for traversal and publish them through atomic pointers.
That split is the project's most interesting claim. A query node can disappear and rebuild its cache without moving the durable graph. Indexers can scale separately from the nodes serving reads and mutations. The design also avoids a writable controller in the graph data path. According to the documented invariants, object storage is both the shared data layer and part of the coordination mechanism.
Writes still need a single authority. HydraDB admits at most one writer for each graph scope and cell. An object-store compare-and-swap lease selects that writer, then SlateDB's writer epoch and write-ahead-log barrier fence off a stale process. Readers pin one SlateDB snapshot for each query. When a traversal index lags, the engine combines its immutable base with the visible log tail, or reads the canonical records directly, as the architecture explains.
This gives the project a clear failure model. Losing a cache should increase latency without losing committed graph data. Losing writer ownership should stop an old node from continuing to commit. The public code also uses SuiteSparse GraphBLAS for some graph operations, while treating every generated matrix as an accelerator rather than the source of truth. These are concrete choices a database engineer can inspect in the repository's code map.
Object storage also appears in the latency contract. HydraDB offers a default causal read mode, which refreshes when a supplied bookmark requires a newer durable sequence, and a strong mode that refreshes the SlateDB reader from object storage before it pins the snapshot. The README describes that second path as paying an object-store freshness cost. Applications choosing strong reads should expect that trade rather than treating S3 as an invisible disk replacement.
A familiar driver does not guarantee query compatibility
Applications can connect through Neo4j-compatible Bolt 5.x drivers or an HTTPS API that returns JSON or streaming NDJSON. That lowers the cost of a trial. It does not make HydraDB a drop-in replacement for every Neo4j workload. The project's Cypher compatibility page says it deliberately implements a subset of OpenCypher and rejects unsupported forms during parsing.
The supported surface covers directed MATCH patterns, property filters, bounded paths, aggregates, CREATE, and batched UNWIND writes. The limits will catch real applications. Each relationship pattern gets one direction and one type. Variable-length traversal must have a maximum. WITH is pass-through only, MERGE lacks ON CREATE and ON MATCH, and RETURN * is unsupported. A team can reuse a driver, but it still has to test its query corpus against those documented boundaries.
The local route is reasonably explicit. HydraDB publishes container instructions for Linux on x86-64 and Arm64, and the README includes an HTTP write followed by a read as its health check. Building from source requires Rust 1.91 or newer, libcypher-parser, and SuiteSparse GraphBLAS. The project's getting-started guide warns that an open port is insufficient evidence and asks the user to round-trip a mutation instead.
The benchmark is narrow and unusually candid
HydraDB's public benchmark is more useful than a context-free latency badge because it exposes the test shape. The data was captured on August 12 using a 15-core Apple Silicon machine, local MinIO in Docker, an in-process harness, and a synthetic layered-fanout graph. Its metadata lists four concurrency and write runs, although some dataset rows report three runs and the engine_rev field is blank. MrKeyoor did not independently rerun these measurements.
On a 200,000-edge synthetic graph, the published data puts a hot one-hop row traversal at a 912-microsecond p50 and the corresponding cold run at 51 milliseconds. A hot 20-hop row traversal on the same graph reached an 11.1-millisecond p50, while its cold p50 was 62.9 milliseconds. Those results describe one local setup and one graph shape. They do not establish performance against a remote cloud bucket or a production graph with a different degree distribution, as the benchmark metadata makes clear.
The write figures reveal a constraint that matters more than the fastest read. On the 200,000-edge case, one concurrent creator produced about 194 writes per second at a 4.9-millisecond p50. With 32 concurrent creators, throughput was about 229 writes per second while p50 latency rose to 138 milliseconds. That is consistent with the architecture's one-writer-per-cell commit path. It also gives prospective users a direct question to test: whether their data can be divided across enough cells without making queries awkward. The figures come from HydraDB's own published dataset.
The repository's proof trail breaks at the important places
The public history is compressed. The current main branch begins with an initial commit dated August 11 and ends with a Dependabot merge on August 13, according to GitHub's commit log. Two tags, v0.1.0 and v0.1.1, are dated August 12. GitHub's Releases page says there are no releases, so users get source tags and container instructions without a normal release page or release notes.
More concerning for a distributed database, the README advertises a correctness casebook, formal verification evidence, a Jepsen consistency report, and a histogram runbook. At reporting time, the linked correctness casebook, formal-methods file, Jepsen report, and runbook all returned 404. The repository tree has no docs directory even though the README lists one.
A broken link does not establish a database fault. It removes the public evidence a reviewer needs to assess claims about writer fencing and consistency under failure. The distinction matters here because HydraDB's storage design depends on behavior across object-store leases, log barriers, snapshots, and asynchronous indexes. A working smoke test can confirm basic reads and writes; it cannot stand in for the missing failure reports cited by the project's own documentation table.
There are smaller signs of incomplete cleanup. The Cargo manifest still names the package slatedb-graph-kernel, sets version 0.1.0, points its repository field at usecortex/slatedb-graph-kernel, and disables publication. None of that proves the engine is unsound. It does tell adopters that the rename and release process have not caught up with the HydraDB branding. The code is also under AGPL-3.0, so license fit belongs in an early technical review.
HydraDB's 794-star day made developers look at a distinctive idea: put the durable graph and its coordination records in object storage, then make query and indexing compute replaceable. The next useful signal will be quieter. Watch for a new main-branch commit, a tagged release with notes, benchmark data pinned to an engine revision, and restored consistency evidence. Until those arrive, the repository is best treated as an interesting system to test against a copy of your workload, rather than a star count to treat as production proof.