How do you decide that a relational system has reached the end of useful vertical scaling and must move to a scale-out architecture, and what evidence would you bring to that decision?

## Reframe the question as runway The useful version of "should we scale out?" is: *on the current trajectory, when does the binding constraint become unmeetable, and what is the lead time of each available remedy?* Scale-out for a relational system is a multi-quarter engineering programme with permanent consequences for what the application can express, so it must be started before the wall, not at it — but starting it for a wall three years away wastes the team. So you need three numbers: current headroom on the binding resource, the growth rate, and the lead time of the remedy. That gives a date, and dates make the decision defensible. ## The four constraints that hardware cannot buy away **1. The single-writer ceiling.** Reads can be offloaded to replicas indefinitely; writes cannot. Once a well-tuned primary — sane indexes, batched writes, short transactions, no hot-row serialization, low-latency log storage — is saturated, no purchase adds writers. Only more primaries do, which means sharding or splitting the write workload out. Evidence: sustained commit-path saturation or contention at peak, with the tuning list demonstrably exhausted. **2. Data volume versus operational windows.** Very large single databases fail on *operations* before they fail on queries. Full backup and, more importantly, **restore** time; index rebuilds; schema migrations that rewrite tables; version cleanup or purge that cannot keep up; major-version upgrades. When restore time exceeds the recovery time objective the business has agreed to, size alone forces a split — though in-server table partitioning frequently rescues this case first, because it makes retention and maintenance per-partition rather than per-table. **3. The cost curve.** Instance pricing is roughly linear through the middle of a family and steepens near the top; the last doubling may cost several times the previous step while delivering a smaller relative gain because the workload does not scale linearly with cores. When the next hardware step costs more than the amortised engineering cost of the split, the economics have flipped. **4. Failure domain and change risk.** One machine holding the entire business is a single blast radius: one bad migration, one corrupted page, one resize gone wrong takes everything down. It also concentrates change risk — every team's schema change lands on the same server, and one team's runaway query is everyone's incident. At some organisational size this alone justifies splitting, independent of capacity. ## Everything you must have tried first A credible scale-out proposal is stronger for listing what it is *not*: - **Query and index work** — the top statements by total time, fixed. This is routinely a 2–10x win. - **Schema and access-pattern work** — removing write amplification, narrowing rows, eliminating hot-row counters, batching. - **Caching** — repeatedly-read, rarely-changing data served from a cache; the cheapest read scaling there is. - **Scale-up** — including a correct diagnosis of the binding resource, so the purchase actually targets it. - **Read offload** — replicas for reporting and read-heavy paths, with an explicit answer for replica staleness. - **Connection discipline** — a global pool budget and a pooler, since connection pressure masquerades as capacity exhaustion. - **Table partitioning inside one server** — turns retention and maintenance into metadata operations and enables pruning, often deferring the split by years. ## Choose the least drastic split that removes the constraint Scale-out is not one thing. In increasing order of cost and irreversibility: 1. **Read offload to replicas** — no data model change; fixes read capacity only. 2. **Functional / vertical split** — move a bounded subsystem (sessions, audit, events, search, metrics) to its own store. Often removes most of the write load with far less complexity than sharding, because the split follows an existing seam in the domain. 3. **Move the wrong-shaped workload out** — time-series, logs, blobs, and full-text often do not belong in the transactional relational store at all. 4. **Shard** — split one entity family across primaries by key. Highest capability, highest cost: cross-shard queries, global uniqueness, distributed transactions, rebalancing, and every operational task multiplied by N. The common failure is skipping to (4) when (2) or (3) would have removed the constraint for a fraction of the effort. ## What the decision document contains - The binding constraint, measured, with the wait or resource evidence. - Growth rate and the projected date of exhaustion, with uncertainty. - Interventions already applied and the headroom each bought. - Cost of the next hardware step versus engineering cost and lead time of the split. - The chosen split, the seam it follows, and explicitly what the application loses (which joins, which transactions, which constraints). - A **reversible first step** — for example, moving one subsystem's writes behind an interface before physically separating it, or introducing a routing layer while all keys still resolve to one shard. Being able to stop halfway without a rollback catastrophe is what makes the programme safe to start. - Operational readiness: N primaries means N of everything — backups, monitoring, failover drills, schema-change pipelines. ## The judgment in one line Stop buying hardware when the constraint stops being a resource and becomes a structure: one writer, one maintenance window, one failure domain, one nonlinear price. Until then, the boring interventions win, and the scale-out capital is better spent later, on a seam you understand.