A team adds five more database servers to a relational cluster and is surprised that overall write throughput barely changes. Why does adding machines fail to multiply write capacity in a typical single-primary relational deployment, and what actually raises that ceiling?

## The shape of a normal relational cluster Almost every mainstream relational deployment is **single-primary**: one node accepts writes, and one or more replicas continuously apply the primary's change stream (a write-ahead log, a binary log, or a statement/row replication feed). This is not an accident. Relational semantics — serializable-ish isolation, unique constraints, foreign keys, ordered commits — are far easier to guarantee when exactly one node decides the order of changes. The consequence: **replicas are copies, not additional writers**. A write is not distributed across the cluster; it is performed once on the primary and then re-performed on each replica. Five extra machines means the same write is now done six times in total, not that six writes happen in parallel. ## Where the ceiling physically lives On the single primary, a write passes through several serializing resources, and the ceiling is whichever saturates first: - **Log flush (fsync) latency.** A durable commit must get the log record to stable storage. This is a latency-bound, largely serial step. It is why commit rate on spinning disks was historically a few hundred per second, and why NVMe and battery-backed caches changed the game so much. - **Index maintenance.** Every index on a table is another structure to update per row change. A table with eight indexes costs several times more per insert than one with two. - **Lock and latch contention.** Rows, pages, and internal structures that many transactions touch (a counter, a sequence, the tail of a hot index, a status column everyone updates) serialize work no matter how many cores exist. - **MVCC bookkeeping.** Engines that keep old row versions must also clean them up (vacuum, purge, undo). At high write rates this maintenance itself becomes a load, and if it falls behind, read performance degrades too. - **Replication back-pressure.** With synchronous replicas, each commit waits for at least one remote acknowledgement, so adding a synchronous replica *lowers* peak write throughput while raising durability. ## Why this is different from the application tier A stateless service scales out by cloning: N identical instances, any of which can serve any request, because none of them owns state. A database owns state, so an added machine must either hold **the same** data (replica — redundancy, no extra write capacity) or **different** data (shard — real extra write capacity, different semantics). There is no third option. Understanding this is the whole point of the question. ## Raising the ceiling without changing topology Before any architecture change, you can often buy a 2–10x margin on the same box: - **Drop unused and redundant indexes.** This is usually the single highest-leverage change for insert/update-heavy tables. - **Batch.** Committing 500 rows in one transaction instead of 500 transactions collapses 500 log flushes into one. Group commit does this automatically for concurrent sessions. - **Shorten transactions.** Never hold a transaction open across a network call or user think-time; the lock hold time, not the work, is what serializes others. - **Remove hot-row patterns.** A single counter row updated by every request is a serialization point; sharded counters or an append-and-aggregate pattern removes it. - **Faster storage and more memory.** Lower fsync latency raises commit rate directly; a working set that fits in memory turns random read IO into CPU. - **Reduce write amplification.** Triggers, over-broad updates that rewrite unchanged columns, and audit tables written synchronously all multiply the cost of each logical write. ## When the ceiling is real, the answers are structural If a well-tuned primary on good hardware still saturates, the options are: 1. **Shard** — multiple primaries, each owning a slice by key. Aggregate write capacity scales with shard count; cross-shard queries and transactions become the new problem. 2. **Functional split** — move a subsystem (sessions, audit, events, metrics) to its own database or to a store designed for that write pattern. Often far cheaper than sharding the whole model. 3. **Change the write pattern** — buffer through a queue and write in batches, precompute instead of updating on every event, or accept eventual materialization. 4. **Multi-primary / active-active** — possible, but it converts a capacity problem into a conflict-resolution problem: two nodes may accept conflicting writes to the same key, and someone must define the reconciliation rule. It rarely gives linear write scaling for a contended workload. ## The one-line takeaway In a single-primary system, writes do not parallelize across machines — they parallelize only across cores, disks, and locks *inside* one machine. More servers give you reads and survival, not write capacity; more primaries give you write capacity, and cost you the ability to join and transact freely across the whole dataset.