hydra-db/hydradb

The problem

Graph databases usually make you choose between a cluster you operate yourself, where storage and compute grow together and rebalancing is painful, and a managed service where cost and lock-in follow. Scaling reads means copying data to more machines; losing a node means rebuilding local state from somewhere. HydraDB addresses this by making S3-compatible object storage the durable source of truth, with query nodes and indexers holding only disposable cache, so compute can be replaced or scaled without moving the graph.

What's different

Most self-hosted graph databases tie storage to the nodes that serve queries, which is why resizing is an operational event. HydraDB separates the two tiers and uses object-store CAS leases plus writer epochs to pick and fence a single active writer per cell, and pins each query to one snapshot for consistent reads. It also leans on GraphBLAS sparse linear algebra for traversal instead of a purely iterator-based executor, and speaks Bolt 5.x, so existing Neo4j drivers work. The trade-off is explicit in the README: staleness is tolerated by design, since reads stay correct while an index is missing or behind by applying the visible WAL tail on top of the indexed base. This is a different bet from an in-memory or locally-attached-disk graph store.

Who it's for

Teams running graph workloads large enough that object storage is cheaper than block storage, and who already have S3 or an S3-compatible store plus Kubernetes-style operations. It suits people who want Neo4j-compatible clients without Neo4j's deployment model. It is a poor fit for single-machine embedded use, for latency-critical traversals that cannot tolerate index lag, or for anyone unwilling to run a Rust build with native C dependencies.

Cost of adoption

The README is honest about the build burden: Rust 1.91+, a C/C++ toolchain, libcypher-parser (not in homebrew-core, requires a tap), and SuiteSparse GraphBLAS. There is no published binary or container path in the getting-started section; you build with just native-check and just smoke, or run cargo run --locked --features server-runtime --bin graph-node. Configuration is a long list of environment variables, and the README itself warns about stack overflows and bindgen include paths. The license is AGPL-3.0, which matters if you plan to offer it as a service. The README is detailed on local development but says little about production hardening, backup, or upgrade paths.

Verdict

HydraDB is a very young project: created in July 2026 and about 113 days old at the time of these signals, with roughly 13k stars and a +8,451 monthly Rust-board gain at #11. That combination of age and star velocity suggests a launch spike rather than a track record, and the absence of Hacker News discussion and daily-board appearances means we have no independent vetting to point to. The architecture is a credible and increasingly common answer to graph scaling, but the operational story is unproven. Worth a prototype if object-store-native graphs are on your roadmap; not something to put behind production traffic yet.