Distributed K/V
without the operational tax.

Yes, with a clear-eyed view of the version. Mesh is v0.12 — the on-disk format and the wire protocol are stable and we will not break them without a migration path, and 1,408 clusters report production telemetry today. What v0.x signals is that the client API surface may still gain methods before 1.0. Mesh runs continuous Jepsen-style partition testing on every release and the storage layer is fuzzed against power-loss injection. Run three or five nodes, keep one version behind the bleeding edge, and it is a sound choice for service discovery, feature flags, leader election, and configuration.

Mesh follows Raft strictly, so it always favors consistency over availability. During a partition only the side holding a majority quorum can elect a leader and accept writes — in a five-node cluster split 3/2, the minority side rejects writes and serves only stale reads it explicitly labels as such. The majority side keeps a leader the whole time; if it was the old leader that got isolated, it steps down within an election timeout. When the partition heals, the stale nodes catch up from the leader's log and rejoin. There is no split-brain and no divergent history — a write that was acknowledged stays acknowledged. Median observed failover is 0.34s.

On a five-node c7g.2xlarge cluster with 256-byte values and a 50/50 read-write mix, Mesh sustains about 184k ops/s with a 1.18ms P99 on writes. Reads served by the leader are linearizable; reads served by followers are bounded-staleness and scale roughly with node count. The ceiling on writes is the Raft commit path — every write needs a majority fsync — so write throughput is gated by your slowest disk and your cross-node RTT, not by CPU. Mesh is built for high-frequency small values, not for pushing gigabytes; if you are saturating it, you are likely storing values that belong in object storage.

mesh snapshot writes a consistent point-in-time image of the keyspace at a known Raft revision — it is safe to run against a live cluster and streams straight to a file or to S3-compatible storage. Restore is mesh restore into a fresh cluster, which replays the snapshot and resumes. For continuous protection, point-in-time recovery ships the Raft log segments after the last snapshot, so you can roll forward to any revision. Snapshots are content-addressed and incremental, so a daily backup of a steady cluster is cheap. We recommend a nightly snapshot plus log shipping; full disaster recovery of a 10 GB keyspace restores in a few minutes.

FoundationDB is a genuinely remarkable piece of engineering and, for the very hardest distributed-storage problems, it is more capable than Mesh — strict-serializable transactions across an enormous keyspace, a deterministic simulation test suite that is the gold standard of the field. It is also a multi-process system with distinct roles (coordinators, storage, transaction logs, proxies) that you size and operate as a unit. Mesh trades that ceiling for an operational floor: one binary, three-node minimum, no roles to plan. If you are building a database or a platform on top of an ordered transactional store, reach for FoundationDB. If you need a replicated K/V store for configuration, coordination, and small stateful data — and you want to run it without a dedicated team — that is exactly the seam Mesh is cut for.