Infrastructure systems often need a small, reliable place to keep control-plane state: configuration, service metadata, locks, leases, revision history, and change notifications.
t4 is an open-source key-value database built on object storage for durable infrastructure state. It started as an attempt to simplify Kubernetes storage. Kubernetes depends on etcd for its control-plane state, and etcd is excellent when you want the full Raft cluster model. But etcd also brings a full consensus cluster, membership management, snapshots, restores, and operational habits that are not always pleasant in small clusters, edge environments, or experiments.
Kubernetes has also moved from a world of big, carefully managed control planes on large servers toward simpler, more disposable hosted control planes. In that world, the storage layer should be easier to replace and easier to recover. The initial question behind t4 was simple: what would Kubernetes-style storage look like if recovery came from object storage instead?
The shape of the problem
Many infrastructure projects need a database that is smaller than a general-purpose SQL system but stronger than a plain local file:
- Configuration needs prefix reads, conditional updates, and watch streams.
- Schedulers and control planes need leases, locks, and monotonically increasing revisions.
- Operators need recovery after node loss without hand-copying snapshots.
- Test and migration workflows benefit from point-in-time copies of live state.
The usual answer is to run a separate coordination database. That works, but it also adds an operational object with its own cluster membership, snapshots, restore procedure, failure modes, and performance profile.
For many systems, especially ones that already trust S3-compatible storage as their durable boundary, that can feel like too much machinery for a small amount of important state.
The object-storage bet
Object storage has become the boring durable substrate. It is cheap, widely available, regionally durable, and already part of the operational model for many platforms.
t4 uses that substrate directly:
- WAL segments record every change.
- Checkpoints provide fast recovery points.
- Content-addressed SST files avoid re-uploading unchanged data.
- Branches share existing checkpoint files instead of copying full databases.
- Leader election uses object-store conditional writes instead of a separate coordination service.
Hot reads still come from local storage. t4 keeps a local Pebble database for the active working set, while object storage carries the recovery story. If a node disappears, loses its disk, or is replaced, it can rebuild from checkpoints and WAL segments in S3-compatible storage.
That model is not "etcd, but implemented differently." It is a different durability model for workloads where object storage is already the source of truth after failure.
What this unlocks
Once the database can recover from object storage, other workflows become much more natural.
Recovery drills stop being special events. You can create a fresh node, point it at the bucket and prefix, and let it rebuild. Migration experiments can start from a known checkpoint. Disposable test environments can fork from real state without copying every object.
The branching feature grew directly out of this. t4 checkpoints use content-addressed SST files, so a branch can reuse the same immutable files as its source and write only its own changes. That makes point-in-time copies cheap enough to use for rehearsal, debugging, and upgrade testing rather than only for emergencies.
This is the part of t4 that feels least like a traditional coordination database: not just storing state, but making state cheap to clone, inspect, and throw away.
Where t4 fits
t4 is built for:
- Durable infrastructure state.
- Simplifying Kubernetes-style control-plane storage.
- Simple replacement of failed or ephemeral nodes.
- Local reads from an embedded or standalone process.
- Existing etcd v3 clients where compatibility matters.
- Copy-free branches for recovery drills, migrations, and tests.
It is aiming to solve operational complexity, not trying to replace every etcd deployment. Use etcd when you want the most mature operational ecosystem, full cluster-management APIs, or the lowest possible latency for small sequential write workloads. The benchmark notes are deliberately explicit about where etcd still leads and where t4's cluster model is stronger.
The code is open source at github.com/t4db/t4. The docs start at t4db.github.io/t4, including the getting started guide, architecture notes, and etcd migration guide.
Top comments (0)