Overview
HydraDB keeps canonical graph records in SlateDB-managed S3-compatible object storage while query nodes and indexers use replaceable local state. Across scope identity, snapshots, traversal, writer fencing, index publication, and client limits, the series shows how durable truth stays authoritative as acceleration lags or disappears. The payoff is rebuildable, independently scalable compute and bounded degradation; the cost is remote I/O, coordination complexity, asynchronous freshness, and a narrower query contract.
Learning outcomes
- Canonical graph records in SlateDB-managed object storage remain authoritative; caches, indexes, and local compute are rebuildable or replaceable.
- Each query pins one snapshot, using causal progress or strong refresh to choose freshness without mixing graph versions.
- Placement, leases, and SlateDB writer epochs separate contention, admission, and final fencing for one-cell mutation authority.
- Asynchronous indexes can lag safely through a bounded overlay or canonical fallback, while unsupported or over-budget work fails explicitly.
- The design fits workloads valuing rebuildability and independent scaling, but pays remote latency, coordination, freshness, and language-contract costs.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What is HydraDB's main architectural trade-off?
HydraDB trades remote object-storage and coordination costs for durable rebuildability and independently replaceable query and indexing compute. Its fit depends on a workload's tolerance for remote latency and bounded execution.
How does HydraDB keep graph queries consistent when indexes lag?
HydraDB pins one storage snapshot, uses an index base plus a committed WAL tail when bounded, and falls back to canonical snapshot adjacency otherwise.
How does HydraDB prevent two nodes from committing the same cell?
HydraDB uses shared liveness and rendezvous placement to choose a contender, an object-store lease to admit one holder, and SlateDB writer epochs to fence stale handles.
What happens when a HydraDB cache or indexer fails?
A lost cache causes cold reconstruction, while an indexer failure leaves canonical graph state intact and shifts readers to an older generation, overlay, or canonical fallback within bounds.