Durability

celld does not release the result of a durable write until a durability proof covers that write. The selected durability posture determines which proof may release the response.

Bucket durability

CELLD_DURABILITY=bucket

Bucket mode always requires an object-store proof, even when other celld nodes are available.

application write
      │
      ▼
local SQLite commit
      │
      ▼
LTX upload to R2
      │
      ▼
ownership verification
      │
      ▼
response released

The object-store round trip is therefore on the write latency path. A bucket proof also verifies that the ownership record still names the node and epoch before revealing the result.

For a single node, this is the natural RPO=0 posture because there is no independent follower disk that can provide a fleet proof.

Fleet durability

CELLD_DURABILITY=fleet

With two or more nodes, the owner can send each write to follower nodes.

                    ┌─ follower fsync ──→ fleet proof
owner commit ───────┤
                    └─ R2 upload ───────→ long-term durability

A healthy fleet can release the response when the follower ensemble has stored the write, or when the bucket proof wins first. The bucket upload continues as the long-term durability path.

Two running nodes are enough to form a fleet proof. Three nodes are preferred because the owner can recruit up to two followers and continue using the fast path when one follower is unavailable.

Why fleet mode lowers R2 Class A pressure

When the bucket itself must prove a write, celld uses per-cell uploads.

Fleet durability can use bundled tiering: dirty segments from multiple cells are combined into node-level flushes before they are tiered into the bucket. This decouples application acknowledgements from a per-write object-store proof and can substantially reduce Class A operation pressure.

The exact reduction depends on workload shape and flush behavior. Treat it as an architectural advantage, not a fixed multiplier for capacity planning.

Why fleet nodes keep persistent local storage

A fleet acknowledgement can complete before the corresponding R2 upload finishes. During that window, follower disks can contain acknowledged writes that the bucket does not yet contain.

That is why Xicar’s fleet profile keeps:

CELLD_WATCH=/var/lib/celld/state

on a persistent local volume for each node.

The volumes are independent. They are not shared across servers and do not need storage-level replication.

Choosing a profile

Use bucket durability when the service is lower-write, R2 latency is acceptable, higher Class A pressure is acceptable, and disposable nodes are operationally valuable.

Use fleet durability when write latency, high-frequency Durable Object state, queues, driver-location or matching state, lower Class A pressure, or maintenance availability matter.

A practical operating rule is: when R2 becomes a performance or cost concern for a single-node service, move the service to the fleet profile rather than weakening the durability guarantee.

Application-level batching

Single-node bucket mode can still reduce object-store pressure by reducing the number of durable commits.

Prefer one transaction containing several related writes over several independently committed mutations. Do not acknowledge application state before the durable commit merely to save R2 operations unless the application explicitly accepts that weaker failure guarantee.