Key takeaways:
- Most production databases still run on configuration decisions made in the first week of their existence
- Defaults and provisional setups don't get revisited because they "work" — until the workload outgrows them
- The real cost shows up as ambient performance loss, slower migrations, painful upgrades, and avoidable audit findings
- Continuous review of configuration and capacity surfaces the gap between how the instance was set up and what its workload actually needs today
Most production SQL Server estates are running on decisions that were made in the first week. Default settings nobody changed. A database file size set by whoever clicked "next" in the install wizard. A backup schedule chosen because it matched the application server's. A service account created with a working set of permissions three iterations ago, that has been carried forward ever since.
It worked then. So it stayed.
The decisions that quietly compound
There is nothing wrong with a default. Defaults exist because they are reasonable in most scenarios. The problem is that "most scenarios" is not the same as "your scenario, three years from now, with five hundred times the data."
The decisions that compound the most are usually the ones nobody made consciously:
- Default tempdb configuration — single file, modest size, autogrow at 10% — on a system that now serves an order of magnitude more workload than it was sized for
- MAXDOP and cost threshold for parallelism left at install-time values, on hardware that has been upgraded twice
- Backup retention written to keep "a few" copies, which has become hundreds, occupying space nobody is auditing
- Service accounts that were granted sysadmin "for setup," and never got demoted afterwards
- A database started on the same server as the application "for the proof of concept" — which became production
Each of these was correct at the moment it was decided. None of them have been actively wrong since. They have just been increasingly suboptimal, on a curve too gentle for anyone to notice.
Why they're hidden
The system works. Nobody investigates working systems. That, on its own, would be enough to keep "for now" decisions buried indefinitely. But several other factors make them harder to find:
- The original team has often moved on, usually without leaving notes on which decisions were provisional and which were intentional
- The configuration has been normalised — it has been like this for years, so anyone new to the system assumes it is the way it is supposed to be
- The cost shows up as ambient performance loss, which gets attributed to other things: the network, the storage, the application, the user count
- The acute cost only surfaces during migrations, upgrades, audits, or scaling events — moments when the team is already busy, and the conversation has to be "why is this set up like this?" with no good answer available
The real cost
The hidden cost of "it works for now" is not theoretical. In a typical estate it shows up as:
- Slower-than-necessary performance, every day, across every workload, in ways no one attributes to the configuration
- Migrations that take three times longer than estimated because nothing was documented and every setting has to be reasoned about from scratch
- Upgrades that surface twenty configuration decisions in a sprint that was supposed to be invisible
- Audit findings on access, retention, and segregation of duties that have been true for years — but that nobody has had to answer for until now
- Higher infrastructure spend, because it is easier to throw hardware at a workload than to revisit the configuration that is constraining it
None of these are anyone's fault. The system worked. Nobody investigates working systems.
That is the whole problem.
Test DB24 for free and learn how we can help
DB24 continuously surfaces the gap between how an instance was set up and what its workload actually needs today — so the "for now" decisions get reviewed before they become "forever" ones.