What HydraDB’s Architecture Buys—and What It Costs
HydraDB's central proposition is simple to state but demanding to implement: a distributed graph database can keep its durable truth in S3-compatible object storage while allowing query and indexing compute to be replaced, scaled, or rebuilt. This final synthesis reconnects the full mechanism stack—from scope and canonical records to snapshots, sparse traversal, leases, immutable indexes, and client limits—and turns it into a conditional judgment. The useful question is not whether object storage is universally better, but when durable rebuildability is worth remote-storage latency and the coordination needed to preserve correctness.
The architecture is easiest to judge by following authority rather than following process names. Ask what each part is allowed to decide. The answer reveals both HydraDB's strength and its cost: it keeps several decisions separate, then spends engineering effort making their boundaries agree.
The proposition is a division of authority
The durable graph lives in SlateDB-managed records on object storage. A scope and cell give those records a stable identity. Vertices, relationships, properties, topology, tombstones, counts, and idempotency state describe committed graph content. The storage engine provides WAL durability, manifests, sorted-string tables, snapshots, compaction, and writer epochs. That is the foundation on which other roles operate.
A query does not treat every available structure as equally authoritative. It pins a SlateDB snapshot at one storage sequence. That snapshot establishes which graph state the query may see. A property index can find candidates, a CSC generation can accelerate topology, and a WAL overlay can bring an older generation forward to the read point. But metadata, deletion state, relationship identity, and other query semantics remain bounded by the same snapshot. If the accelerated route cannot establish that view within its work limits, HydraDB falls back to canonical snapshot adjacency or returns an explicit bounded error.
A mutation has a different authority path. Liveness and rendezvous placement identify which node should contend for a scope and cell. An object-store CAS lease admits one holder. SlateDB's writer epoch and WAL barrier prevent a stale handle from committing. A successful mutation updates the canonical records and its topology changelog at the storage durability boundary. An idempotency key gives a retry durable identity; it is not confused with an ephemeral query ID.
The indexer sits beside, not inside, that write authority. It reads dirty topology, builds an immutable traversal generation, and advances a current pointer conditionally. Its local reader handles, parsed WAL files, and working memory can disappear. Its published output can lag. Its failure changes how much work a reader must do, but it does not redefine the graph or prevent a canonical write merely because the materialization is unavailable.
This is why “replaceable compute” is more precise than “stateless servers.” The servers do hold state while they work: snapshots, cursors, caches, leases, and compiled matrices. The claim is that those states have bounded lifecycles and explicit authorities. A cache can be reconstructed. A result cursor can expire. A query snapshot ends with the query. A writer lease can be renewed or lost. A generation can be replaced by a newer one. What cannot be casually replaced is the durable record that says what was committed.
One end-to-end invariant stack
Imagine a workload that writes relationships, asks for bounded paths, and runs across several Kubernetes Pods. A client first addresses a namespace, graph, and cell. That identity selects the durable location and the scope against which authorization and placement are evaluated. It is the first guard against using a valid record in the wrong graph.
For a write, the routed node checks the shared liveness view and rendezvous result. If a live peer is the expected contender, the request is routed or refused with a hint. If the node's view is shed and therefore unknown, it refuses without a stale hint. If the node is allowed to contend, it acquires or renews the object-store lease through CAS, promotes a SlateDB writer epoch, verifies the lease still holds, and commits the mutation.