Why Orbita
Orbita exists because every system I have used for control plane state asked me to pay for it in a different way. This page explains where the project came from and what it is trying to fix, because the best way to evaluate a coordination store is to understand the failures that shaped it.
The Redis era
I have typically leaned on Redis as the source of truth for control planes. It acts as shared memory, and its collection of data structures makes it easy to model rate limits, quotas, epochs, mutexes, leader election, and similar coordination state. I used that strategy when building Tower, and it worked, but a few problems kept coming back.
Durability was always a question. Redis can run in a durable mode, but crash recovery is expensive enough that you plan around it. Coordination state is exactly the data you cannot afford to lose or reconstruct by hand.
Memory residency. The dataset cannot outgrow memory. When it grows, the only answer is more memory, which turns a data problem into a capacity planning problem.
Tooling. We had to build all of our own tooling for exploring the state of our control plane, which got expensive. State you cannot examine with ordinary tools is state you cannot trust.
Hosting. ElastiCache is a decent hosted option on AWS, but it lacks a cloud native authentication scheme and real multi-tenancy features. The operational surface around the store cost as much as the store itself.
The alternatives each cost too much
The systems built for this job trade those problems for different ones.
At Snowflake we used FoundationDB and got amazing results from it, but we had a massive team maintaining it and contributing to it. That operating model works at Snowflake’s scale. It is not available to a platform team of five.
Tower’s control plane store originally ran on etcd. It is proven and direct, but operating it was likewise complicated, and its single consensus group and bounded backend become more visible as data grows.
I used ZooKeeper at Cloudability, and it was amazingly fragile. It predates most of what we now expect from operational tooling, and it showed.
I looked at DynamoDB, and the managed serverless model is genuinely appealing, but its pricing got expensive for a workload this chatty. Coordination state is small, but it is read and written constantly.
What Orbita is
What I always wanted was a store for control plane state that had:
- Redis-like performance on the fast path, because coordination sits on the critical path of everything above it;
- durability by default, with recovery that is routine rather than an event;
- datasets that outgrow memory, backed by object storage instead of RAM;
- operational simplicity, one process to start and no dedicated team to keep it healthy;
- good tooling with standard interfaces, so the state of your control plane is inspectable without building your own explorers.
That is why I built Orbita. It is a strongly consistent key-value store with ordered keys, conditional writes, and absolute TTLs, designed for locks, leases, catalogs, epochs, and ownership records. It starts as one process and grows by adding range-partitioned workers, while bulk durability lives in S3-compatible object storage.
Orbita itself is a data store, not a hosted service. I plan to one day build a service that uses Orbita as its primary store, but Orbita is the thing you run.
Where to go next
- Quick start: run Orbita locally in one command.
- Architecture: how the WAL, object storage, and range partitions fit together.
- Manifesto: what we believe a control-plane datastore owes its operators.