Clustering (preview): not yet available for deployment

Most workloads run comfortably on a single Aito node: one process backed by local SSD, with environments for branching and backups. That is the supported way to run Aito today, and it scales further than many workloads need (see Performance).

If you expect to outgrow a single node (read or write throughput, availability, or object-store-backed durability), tell us: support@aito.ai with a sketch of your workload (rows, write rate, query rate, latency target). Real requirements shape what gets built first.

The design: a database that lives in the object store (design intent)

Aito's distributed design is disaggregated: a shared object store is the single source of truth, and compute nodes act as caches in front of it.

• The object store holds every version of the data as immutable, content-named blobs.
• Each node keeps a fast local copy (SSD/RAM) of the slice it serves and pulls anything it is missing from the store on demand.
• There is no replication protocol and no consensus group in the data path: the object store's own atomicity is the coordination primitive.

How it is meant to work (design intent)

Immutable, content-addressed blobs. Everything Aito persists is named by the hash of its contents, so a name always means exactly one immutable value. That is what makes blobs safe to copy, cache and share between nodes with no invalidation logic. (This part is true of single-node Aito today.)

Writes commit by moving one small reference. A writer uploads its new blobs, then commits by atomically advancing a small state reference in the store (a fenced compare-and-swap with a monotonic epoch). A commit either wins the CAS and becomes visible, or loses and rebases and retries, so concurrent writers do not lose each other's updates.

Reads follow the reference. A reader opens the same store, reads the current state reference, and pulls the blobs it points at on a cache miss.

Warm data is local; cold data costs a fetch. A query whose data a node has already cached is served at single-node speed. The first access to uncached data pulls it from the store. The design hides that with prefetch on commit and a background-warmed serving view.

Design goals (no dates)

None of the following is available. They are design goals, not commitments:

• Configuring and running a multi-node deployment at all, including the store configuration a cluster needs.
• High availability: the current design has a single coordinator that would need manual promotion; losing and replacing nodes without downtime is a goal, not built.
• Read scale-out behind a load balancer: reader nodes as independent caches, so read capacity grows with node count. Request routing is not built.
• Write scale-out by sharding the state reference per collection or tenant, so writers to different shards proceed in parallel. Not wired into the live write path.
• Tunable staleness for a warmed read fleet: a configurable freshness vs. latency trade-off. It is not configurable today.
• Backup and restore as an object-store operation, with the store's own durability and versioning as the source of truth.
• Disposable nodes: a lost node recovering by re-warming from the store. Automatic recovery of a lost node is not built yet.

What to use today

• One node, sized to the workload: see Performance and Warming strategies.
• Environments for branching, transactions and backups.
• support@aito.ai if a single node will not be enough. We would rather hear about the requirement now than after you have designed around a cluster that does not exist yet.