When is a centralised architecture with a single relational database and vertically scaled application the right answer?

When it is right

When the workload fits and the change volume does not require independent deployment. Concretely:

• Traffic is predictable and within a single primary's capacity, which is far higher than most teams assume — modern instances handle very substantial workloads.
• The working set fits in memory, so the buffer cache is effective.
• Few teams change the code, so coordinated deployment is not a bottleneck.
• Transactions are genuinely useful, and the domain has invariants spanning entities.
• The team is small, and operating one stateful system well is achievable where operating six is not.

For a very large share of products, all of these hold — and the centralised design avoids costs that are permanent: no eventual consistency where a transaction would do, no distributed tracing required to answer basic questions, no saga where an ACID transaction was available, one place to debug.

What must be true to keep it viable

• Enforced internal module boundaries, so it does not become a big ball of mud — which is the actual failure mode, not size.
• Read replicas for read scaling, with the small set of reads requiring freshness routed to the primary.
• A queue in the same database for background work, so enqueue is part of the transaction that created the work.
• Vertical headroom deliberately preserved, since the cheapest scaling step is the next instance size.

The evidence that would change the answer

Write throughput approaching the primary's sustained ceiling with no cheap wins remaining, a working set materially exceeding memory, routine operations no longer fitting the maintenance window, or teams blocking each other on releases.

Each is measurable, and each points at a specific next step rather than at wholesale distribution.

The framing

Distribution is a cost paid to buy independent scaling or independent deployment. A system needing neither should not pay it — and "we might need it later" is a reason to keep boundaries clean, not a reason to distribute now.

The most expensive architectural error in practice is adopting the solution for a problem an order of magnitude larger than the one you have, and paying its complexity every day until you get there — if you ever do.