In many environments, there is a quiet compromise that gets made every day. It rarely shows up in project plans or architecture diagrams. No one formally approves it. But it happens, nonetheless. “Good enough” SQL gets promoted to production.
And, at first, it seems harmless. The query returns the correct results. Performance is acceptable during testing. The application meets its SLA. Everyone moves on. But, in a high-volume environment, “good enough” is rarely good enough for long.
The Multiplier Effect of Scale
A defining characteristic of high-usage database applications is scale. We are not talking about a few hundred executions per day. We are talking about thousands, sometimes millions, of executions of the same SQL statement. And, at that scale, small inefficiencies do not remain small.
An extra access here, an unnecessary sort there, a non-matching index access instead of a matching one. Each individual execution may only be marginally less efficient. But multiply that by millions, and the cost becomes significant.
CPU consumption rises, elapsed times creep upward, buffer pools experience more pressure. And, suddenly, that “good enough” query is contributing to real resource contention. This is a fundamental problem because SQL does not execute in isolation: It executes at scale.
When ‘Acceptable’ Becomes Expensive
During development and testing, SQL is often evaluated under limited conditions: smaller data volumes, fewer concurrent users, controlled workloads. Under those circumstances, many access paths appear acceptable. A table scan instead of an index access may not raise alarms. A sort may complete quickly. A suboptimal join order might not be noticeable.
But production is a different world. Data volumes grow, concurrency increases, workloads overlap, and what was once acceptable becomes expensive.
Consider a simple example. A query that performs a table scan against a moderately sized table might run in a fraction of a second in test. In production, with significantly larger volumes and competing workloads, that same scan can drive up I/O, consume memory for buffering the data, and impact other applications. The SQL did not change; the environment did.
The Hidden CPU Tax
One of the most insidious aspects of “good enough” SQL is the hidden CPU tax it imposes. Sometimes, CPU consumption can incur significant costs. For example, IBM Z CPU is not just a technical metric, it is a business cost. Increased CPU consumption can translate directly into higher software licensing costs and greater pressure on capacity planning.
I have seen environments where a handful of inefficient SQL statements accounted for a disproportionate percentage of total CPU usage. Not because they were complex. Not because they were poorly written in an obvious way. But because they were executed so frequently.
Each execution paid a small penalty. The system paid the aggregate bill. This is where “good enough” becomes a financial issue, not just a technical one.
Access Paths Matter More Than You Think
At the heart of SQL performance is the query optimizer. Given a set of statistics and available access paths, the optimizer in the DBMS chooses what it believes to be the most efficient way to execute a query. But the optimizer can only work with what it is given. If indexes are poorly designed, if statistics are stale, or if the SQL itself is written in a way that limits optimization, the resulting access path may be suboptimal.
“Good enough” SQL often relies on whatever access path the DBMS happens to choose at the time. There is little effort to validate whether that access path is truly efficient, or whether it will remain stable as data changes. Over time, this leads to unpredictability.
Updating database statistics. A DBMS version upgrade. A change in data distribution. Any of these can result in a different access path. If the original SQL was not well-constructed, the new access path may be significantly worse. And, that means what was once acceptable no longer is.
The Cumulative Effect on the System
It is tempting to evaluate SQL performance statement by statement. But, in a high-volume environment, the real impact is cumulative. Multiple “good enough” queries executing concurrently can create systemic issues.
Buffers become less effective due to unnecessary I/O. Locking and contention may increase as queries run longer than necessary. Batch windows can expand. Online response times can degrade.
Individually, each query might pass a performance test. Collectively, they can stress the system.
This is why focusing only on individual SQL statements misses the bigger picture. The goal is not just to make each query acceptable. The goal is to ensure the overall workload is efficient.
Why This Keeps Happening
If the costs are so clear, why does “good enough” SQL persist? Part of the answer is time pressure. Development teams are measured on delivery. If the SQL works and meets immediate requirements, there is little incentive to refine it further.
Another factor is tooling. Modern tools can generate SQL, suggest indexes, and even recommend access paths. These are valuable capabilities, but they can also create a false sense of confidence.
Just because a tool says the SQL is acceptable does not mean it is optimal.
Next comes the gradual erosion of deep database expertise. Understanding how the optimizer works, how access paths are chosen, and how to design efficient SQL requires experience. As that experience becomes less common, the ability to recognize suboptimal SQL diminishes. Then, “good enough” becomes the default.
Raising the Bar
Addressing this issue does not require perfection. It requires intent. It starts with recognizing that SQL performance is not a one-time activity—it is an ongoing discipline.
SQL should be reviewed not just for correctness, but for efficiency. Access paths should be examined and understood. Index design should be deliberate, not reactive.
Equally important is revisiting SQL over time. What was efficient last year may not be efficient today. Data changes. Workloads evolve. Periodic review is essential.
There is also a cultural component. Teams need to value performance as much as functionality. That does not mean delaying every project in pursuit of the perfect query. It means avoiding the assumption that “good enough” is sufficient in a high-volume environment.
The Bottom Line
In a low-volume system, “good enough” SQL might truly be good enough. In a high-volume environment, it rarely is. The cost is not always immediate. It accumulates quietly. Extra CPU cycles. Increased I/O. Longer elapsed times. Greater contention.
Then, one day, it is no longer quiet. And by then, the system is paying for thousands (or millions) of small inefficiencies that were never addressed. The lesson is simple: SQL does not exist in a vacuum, it exists at scale. And, at scale, “good enough” can be surprisingly expensive.