[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"readme:hydradb":3},"\u003Ch1>HydraDB\u003C\u002Fh1>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhydra-db\u002Fhydradb\u002Factions\u002Fworkflows\u002Fcontainer.yml\" rel=\"nofollow ugc noopener\">\u003Cimg src=\"https:\u002F\u002Fgithub.com\u002Fhydra-db\u002Fhydradb\u002Factions\u002Fworkflows\u002Fcontainer.yml\u002Fbadge.svg\" alt=\"Container image\" \u002F>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhydra-db\u002Fhydradb\u002Factions\u002Fworkflows\u002Fopencypher-tck.yml\" rel=\"nofollow ugc noopener\">\u003Cimg src=\"https:\u002F\u002Fgithub.com\u002Fhydra-db\u002Fhydradb\u002Factions\u002Fworkflows\u002Fopencypher-tck.yml\u002Fbadge.svg\" alt=\"OpenCypher TCK\" \u002F>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhydra-db\u002Fhydradb\u002Fblob\u002FHEAD\u002FLICENSE\" rel=\"nofollow ugc noopener\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Flicense-AGPL--3.0-blue.svg\" alt=\"License: AGPL-3.0\" \u002F>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhydra-db\u002Fhydradb\u002Fblob\u002FHEAD\u002Frust-toolchain.toml\" rel=\"nofollow ugc noopener\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Frust-1.91%2B-orange.svg\" alt=\"Rust 1.91+\" \u002F>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fhydra-db.github.io\u002Fbenchmark\u002F\" rel=\"nofollow ugc noopener\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fbenchmarks-live-brightgreen.svg\" alt=\"Benchmarks\" \u002F>\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>HydraDB is an object-store-native distributed graph database written in Rust.\nIt combines durable graph storage on SlateDB with snapshot-consistent\nOpenCypher queries, GraphBLAS traversal, Neo4j-compatible Bolt connectivity,\nand an HTTPS query API.\u003C\u002Fp>\n\u003Cp>Storage and compute are fully disaggregated. S3-compatible object storage is the\ndurable source of truth, and compute runs as two independent roles: \u003Cstrong>data\nnodes\u003C\u002Fstrong> (\u003Ccode>graph-node\u003C\u002Fcode>) serve queries and canonical mutations, while \u003Cstrong>indexers\u003C\u002Fstrong>\n(\u003Ccode>graph-indexer\u003C\u002Fcode>) build immutable traversal indexes in the background. Both keep\nonly disposable state in memory and on local SSD or NVMe, so they can be replaced\nor scaled without moving the graph itself.\u003C\u002Fp>\n\u003Ch2>Why HydraDB\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Object-store durability.\u003C\u002Fstrong> Graph records, WALs, manifests, and immutable\ntraversal indexes live in S3-compatible storage.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Independent compute.\u003C\u002Fstrong> Data nodes and indexers scale separately and can\nrebuild their local caches from durable state.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Safe writer handoff.\u003C\u002Fstrong> Object-store CAS leases select the active writer for\neach cell, while SlateDB writer epochs fence stale writers.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Consistent reads.\u003C\u002Fstrong> Every query runs against one pinned SlateDB snapshot.\nIndexed traversal combines a compiled CSC generation with its visible WAL\noverlay.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Graph-native execution.\u003C\u002Fstrong> The planner uses property indexes, reverse\nadjacency, sparse traversal, and SuiteSparse GraphBLAS where appropriate.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Familiar clients.\u003C\u002Fstrong> Applications can use Neo4j drivers over Bolt 5.x or the\ntyped JSON and streaming NDJSON HTTP API.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Bounded operation.\u003C\u002Fstrong> Authentication, authorization, deadlines, result\nlimits, backpressure, cancellation, cache budgets, metrics, and traces are\npart of the server runtime.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Architecture\u003C\u002Fh2>\n\u003Cpre>\u003Ccode class=\"language-mermaid\">flowchart TB\n    C[\"Applications<br\u002F>Neo4j drivers or HTTPS\"]\n    SVC[\"Service or load balancer\"]\n\n    subgraph Q[\"Data tier — graph-node\"]\n        direction LR\n        subgraph N1[\"graph-node\"]\n            Q1[\"query + mutation engine\"]\n            S1[\"local SSD \u002F NVMe cache\"]\n            Q1 <--> S1\n        end\n        subgraph N2[\"graph-node\"]\n            Q2[\"query + mutation engine\"]\n            S2[\"local SSD \u002F NVMe cache\"]\n            Q2 <--> S2\n        end\n    end\n\n    subgraph I[\"Indexing tier — graph-indexer\"]\n        IX1[\"graph-indexer\"]\n        IXN[\"graph-indexer\"]\n    end\n\n    STORE[\"S3-compatible object storage<br\u002F>WAL, SSTs, leases, CSC generations\"]\n\n    C --> SVC\n    SVC --> N1\n    SVC --> N2\n    N1 <--> STORE\n    N2 <--> STORE\n    IX1 <--> STORE\n    IXN <--> STORE\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Each data node owns a private local SSD\u002FNVMe cache; the object store is the shared\nlayer beneath the whole tier and the only durable copy of the graph.\u003C\u002Fp>\n\u003Cp>Data nodes serve reads and canonical graph mutations. Indexer workers build\nimmutable CSC generations asynchronously and publish them through atomic\nobject-store pointers. Readers remain correct when an index is absent or behind\nbecause the visible WAL tail is applied to the indexed base.\u003C\u002Fp>\n\u003Cp>See \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhydra-db\u002Fhydradb\u002Fblob\u002FHEAD\u002Farchitecture.md\" rel=\"nofollow ugc noopener\">architecture.md\u003C\u002Fa> for the storage model, query pipeline,\nwriter coordination, index lifecycle, and failure semantics.\u003C\u002Fp>\n\u003Ch2>Getting Started\u003C\u002Fh2>\n\u003Cp>There are two ways to bring up a single development node: the published \u003Cstrong>Docker\nimage\u003C\u002Fstrong>, or a \u003Cstrong>build from source\u003C\u002Fstrong>. Either way, once the node is listening, use\n[Verify a running node](#verify\u003C\u002Fp>\n",1789121863023]