Manifesto

This document explains why Orbita needs to exist, what we believe a control-plane datastore should provide, and which tradeoffs the project refuses to hide. It matters because Orbita asks teams to trust it with the state that tells a larger system who owns what, what is current, and what may happen next. That trust has to be earned with reasoning, not asserted with adjectives.

Small state becomes a large responsibility

The amount of coordination data in a platform is usually small. Its consequences are not. Locks, leases, epochs, catalogs, quotas, and ownership records are a few important rows, but one wrong answer can damage something much larger than the store that held it.

Teams have historically served this state from whatever was closest at hand: a cache pressed into duty as shared memory, a consensus store adopted for one feature, or a general-purpose database with an operating model far larger than the problem. All of these work at first. All of them accumulate cost as more of the platform depends on them.

What a control-plane datastore should provide

We believe a datastore built for this job owes its operators five things.

Durability that is not a question. Acknowledged writes survive crashes, and recovery is routine rather than an event you plan around. Coordination state is exactly the data you cannot afford to reconstruct by hand.

Capacity that outgrows memory. The working set should be able to grow past what fits in RAM without forcing a migration to a different system. The store you adopt early should be the store you still run later.

Redis-like latency on the fast path. Coordination sits on the critical path of everything above it. A store that is durable but slow just moves the pressure somewhere else.

Operational simplicity. One process to start, a small surface to understand, and no dedicated team required to keep it healthy. If operating the store is a project, the store has failed at its job.

Tooling with standard interfaces. Operators should be able to inspect the state of their control plane with ordinary tools instead of building their own. State you cannot examine is state you cannot trust.

The tradeoffs we refuse to hide

Orbita makes deliberate choices, and each one costs something.

It is narrow on purpose. Orbita is a key-value store for coordination state. It is not an application database, a cache, an object store, or a hosted service. If you need secondary indexes, analytics, or a query language, you need a different system, which is fine.

Bulk durability lives in object storage. This makes workers replaceable and capacity cheap, and it means cold reads can be slower than a system that keeps everything on local disk. The replicated WAL keeps the write path fast; the tradeoff lands on rarely-touched data.

Claims wait for evidence. Orbita is under active development and is not production-ready. Deterministic simulation, replayable failure schedules, and published requirements are how we intend to prove the safety argument, and until that evidence is published we describe it as a method, not a completed proof.

Correctness is part of the product. The requirements, architecture decisions, and simulation results are public so that the reasoning can be inspected rather than taken on faith. When the evidence and the claim disagree, the claim changes.

Where this goes

Orbita is a data store you run. It is not a hosted service, and it is not positioned as one. We do expect services to be built on top of it, and the project is designed so that a store this small in surface can still carry that weight: start with one process, grow with the system around it, and stay legible the whole way.