Clusters & Scaling (v2, Beta)

Most workloads run comfortably on a single Aito node — one process backed by local SSD, with environments for branching and backups. You should consider a cluster — Aito spread across multiple nodes — when you need one or more of:

• Read scale-out — more concurrent queries than a single node serves.
• Higher write throughput — many independent writers ingesting in parallel.
• High availability — nodes you can lose and replace without losing data.
• Object-store-backed durability — your data's source of truth on S3 (or Azure Blob), with the object store handling durability and backup.

Clustered deployments are set up together with Aito support — the topology, sharding, and object-store configuration are tuned to your throughput, latency, and availability targets. This page explains how the cluster works and what performance characteristics to expect, so you can size a request.

The model: a database that lives in the object store

Aito's distributed design is disaggregated: a shared object store (Amazon S3, with Azure Blob support planned) is the single source of truth, and compute nodes are caches in front of it.

• The object store holds every version of your data as immutable, content-named blobs. Durability, backup, and IO scaling are the object store's job — Aito doesn't build its own replication layer.
• Each node keeps a fast local copy (SSD/RAM) of the slice it serves and pulls anything it's missing from the store on demand.
• Nodes are disposable. Losing a node loses no data — it held only a cache; a replacement warms itself from the store.

There is no replication protocol and no consensus group in the data path. The object store's own atomicity is the coordination primitive, which keeps the system simple and its failure modes easy to reason about.

How it works

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's what makes blobs safe to copy, cache, and share between nodes with no invalidation logic.

Writes commit by moving one small reference. A writer uploads its new blobs, then commits by atomically advancing a tiny state reference in the object store (a fenced compare-and-swap with a monotonic epoch). The commit either wins the CAS and becomes visible, or loses and rebases and retries — so concurrent writers never 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). Readers are independent and share nothing but the store.

Read throughput scales with nodes

Because reader nodes are independent caches over shared storage and coordinate nothing on the read path, read capacity scales roughly linearly with the number of nodes — N reader nodes give about N× the query throughput. Scaling reads is a matter of adding nodes behind a load balancer.

Write throughput scales by sharding

Writes to a single state reference are safe but serialized: the fenced CAS orders them correctly, so adding writers to one line adds contention, not throughput.

Horizontal write throughput comes from sharding the reference by key — typically per collection or per tenant. Each shard is an independent line with its own reference, so writers to different shards never touch the same reference and proceed fully in parallel. Write throughput then scales with the number of shards; contention only ever appears within a shard, where ordering still matters.

Choosing the shard key (collection, tenant, or a composite) to match your write distribution is part of the deployment design we do with you.

Latency

• Warm data is local. A query whose data is already in a node's local cache is served from SSD/RAM at single-node speed — the object store is not on that path.
• Cold data costs a fetch. The first access to data a node hasn't cached pulls it from the object store, adding a round-trip. Two mechanisms hide this:
  • Prefetch on commit — when a node advances to a new state, it fetches the new version's blobs in parallel up front instead of paying many sequential on-miss round-trips.
  • Warm serving view — a background warmer keeps the latest state fully warmed and swaps it in atomically, so live queries pay zero remote round-trips; the object-store fetch happens off the query path entirely.

Staleness & consistency

The state reference is the consistency point. After a writer commits, that version is the new source of truth; a reader becomes consistent with it as soon as it advances to that reference.

The warm serving view trades a bounded amount of freshness for latency: it serves the last fully-warmed state, so it can lag the newest write by up to the warm-up interval. This interval is configurable — shorter for fresher reads, longer to amortize warming — letting you tune the freshness vs. latency balance per deployment. Applications that need read-your-writes on a specific value can address the writer node (or the latest reference) directly.

In short: within a reference, commits are atomic and consistent; across a warmed read fleet, reads are eventually consistent with a bounded, tunable staleness.

Durability & backup

Durability and backup are the object store's responsibility, not a replication layer Aito maintains. Your data's source of truth is S3 (or Azure Blob), with the store's own durability guarantees and versioning. Compute nodes hold only caches, so node loss is not data loss, and backup/restore is an object-store operation rather than a database-specific procedure.

Getting a cluster

Single-node Aito already scales further than many workloads need, and environments give you branching and backups without a cluster. When you do need horizontal scale or high availability, a clustered deployment is stood up with Aito support, sized to your workload.

Contact support@aito.ai with:

• approximate data size (rows / GB) and growth rate,
• write rate (ingests per second, batch vs. streaming) and how it splits across collections or tenants,
• query rate and latency target,
• availability requirements (acceptable downtime, region needs),

and we'll propose a topology — node count, shard key, object-store setup — and help you deploy it.