|
12 | 12 | > [!IMPORTANT] |
13 | 13 | > Under active development. Not production-ready. |
14 | 14 |
|
15 | | -[InferaDB](https://inferadb.com) Ledger is a distributed blockchain database optimized for authorization workloads. It commits every state change cryptographically, replicates via Raft consensus, and lets clients verify independently. Ledger is the persistent storage layer used by the [InferaDB Engine](https://github.com/inferadb/engine) and [InferaDB Control](https://github.com/inferadb/control). |
| 15 | +**[InferaDB](https://inferadb.com) Ledger is a distributed database purpose-built for authorization.** Every permission change is committed to an append-only blockchain, replicated via Raft consensus, and independently verifiable by clients through Merkle proofs — giving you a tamper-proof record of who had access to what, when. Ledger is the storage layer behind [InferaDB Engine](https://github.com/inferadb/engine) and [InferaDB Control](https://github.com/inferadb/control). |
16 | 16 |
|
17 | 17 | - [Features](#features) |
18 | 18 | - [Quick Start](#quick-start) |
|
24 | 24 |
|
25 | 25 | ## Features |
26 | 26 |
|
27 | | -- **Sub-millisecond Reads** — O(1) lookups via B+ tree indexes, no merkle overhead on hot path |
28 | | -- **Cryptographic Auditability** — Per-vault blockchain with chain-linked state roots, SHA-256 commitments, tamper-evident history |
29 | | -- **Strong Consistency** — Raft consensus ensures permission changes are immediately visible cluster-wide |
30 | | -- **Fault Isolation** — Per-vault chains prevent failures from cascading across tenants |
31 | | -- **Horizontal Scaling** — Shard groups distribute organizations across independent Raft clusters |
| 27 | +- **Tamper-Proof Authorization History** — Every permission change is committed to a per-vault blockchain. Not even database administrators can retroactively alter who had access to what, when. |
| 28 | +- **Client-Side Proof Verification** — Clients receive Merkle proofs with every read and can verify authorization decisions independently, without trusting the server. |
| 29 | +- **Data Residency** — Pin authorization data to geographic regions. Nodes only join Raft groups for their assigned region, keeping data within jurisdictional boundaries. |
| 30 | +- **Tenant Isolation** — Per-organization, per-vault security boundaries. Each vault maintains its own blockchain — one tenant's data can never leak into another's. |
| 31 | +- **Immediate Consistency** — Raft consensus ensures permission changes are visible cluster-wide before the write returns. No stale reads on authorization decisions. |
| 32 | +- **Sub-Millisecond Reads** — B+ tree indexes serve lookups without touching the Merkle layer. Cryptographic verification adds no overhead to the hot path. |
32 | 33 |
|
33 | 34 | ## Quick Start |
34 | 35 |
|
@@ -61,6 +62,7 @@ See the [deployment guide](docs/operations/deployment.md) for multi-node setup, |
61 | 62 | | `--join` | Add this server to an existing cluster ([details](docs/operations/deployment.md#adding-a-node)) | | |
62 | 63 | | `--cluster` | Start a new N-node cluster ([details](docs/operations/deployment.md#multi-node-cluster-3-nodes)) | `3` | |
63 | 64 | | `--peers` | How to [find other nodes](docs/operations/deployment.md#discovery-options): DNS domain or file path | _(disabled)_ | |
| 65 | +| `--region` | Geographic [region](docs/operations/deployment.md) for data residency (`us-east-va`, `ie-east-dublin`) | `global` | |
64 | 66 |
|
65 | 67 | See [Configuration Reference](docs/operations/deployment.md#configuration-reference) for environment variables and all options including metrics, batching, and tuning. |
66 | 68 |
|
|
0 commit comments