The Normalization of Waste
Modern software systems routinely overestimate compute requirements. This overestimation is not benign. It drives premature scaling, masks pathological inefficiencies, and produces a cost structure that feels inevitable. Benchmarks like HammerDB expose the glaring void between actual hardware capability and typical business demand. The deployment of a 4xlarge database instance is rarely a sign of hyper-growth. It is a late-stage symptom of failure.
The Illusion of Scale
HammerDB’s NOPM (New Orders Per Minute) is not a vanity metric. It is a concrete measure of sustained OLTP throughput. A baseline of 1,000 NOPM translates to roughly 1.4 million orders per day. Scaling to 10,000 NOPM pushes into 14.4 million orders.
These are not edge cases. Single-digit thousands of NOPM exceed what the vast majority of startups will process at absolute peak. Tens of thousands of NOPM move into the territory of massive financial platforms. NOPM grows exponentially faster than real business demand. This asymmetry destroys the justification for massive infrastructure.
The Power of a Single Core
AWS benchmarks for PostgreSQL on Graviton (r8g) instances yield between 17,000 and 25,000 NOPM per core. This is the critical, suppressed reality: a single modern server core is brutally powerful.
An xlarge instance wielding 4 to 8 cores represents vast, untapped headroom. Scaling beyond an xlarge is not a default architectural decision. It is an anomaly. Most systems will fracture at the query or architectural level long before they exhaust raw CPU. If a system cannot survive within an xlarge envelope, it does not need more cores. It is simply wasting the ones it already has.
The Local Benchmark
Modern laptops are not toys. Even heavily derated, a local development machine without NUMA optimization or server-grade tuning can deliver 10,000 to 30,000 total NOPM at sub-100ms latency. Raw throughput is almost never the reason a team must abandon local environments.
Staying local enforces absolute efficiency. It provides zero infrastructure tax and immediate feedback loops. Teams should migrate to remote servers for operational imperatives like availability and backups, not because they have mathematically outgrown the hardware.
The Inevitability of Collapse
If instance size scales faster than business revenue, the architecture is deeply broken. Bad queries, N+1 access patterns, fan-out reads, and unindexed joins consume CPU faster than they generate user value.
Vertical scaling does not solve these pathologies. It subsidizes them. The complaint that a “2xlarge is too expensive” is a late-stage manifestation. By this point, query paths are fragile. Inefficiency is perceived as “hard-won” performance. The system did not become inefficient because it was placed on a large instance; it requires a large instance because inefficiency was normalized.
The Final Verdict
When faced with crushing infrastructure bills, engineering teams deploy a post-hoc rationalization: “These instances are powerful, so of course they are expensive.” They reframe a fatal symptom as a virtue.
Hardware capacity is abundant. Engineering efficiency is extinct. An xlarge instance is an extraordinarily powerful machine. When systems grow into 2xlarge and 4xlarge territory without commensurate revenue, the issue is not scale. It is waste that has been deferred, normalized, and finally monetized. Large cloud bills are the penalty for using vertical scaling as duct tape.