Your database is slowing the business down. Here is why performance needs an owner.

Most databases do not fail all at once. They slow down a little at a time, and people work around it.

A screen that loaded right away now takes a few seconds. The month-end report gets started before lunch. Someone adds "just rerun it" to the training notes. Then the database moves up a cloud tier, and nobody can say why it needed to.

I have spent 26 years in database administration and development, and the pattern has barely changed. If nobody owns database performance, it gets managed by complaint. Here is what active management looks like on SQL Server, PostgreSQL, Oracle, or anything else, and when to bring in help.

What slow queries actually cost

A slow query rarely makes it onto a budget line, but it costs you anyway.

Staff waiting. Say an order-entry screen takes 8 seconds to save, and your team saves it a few hundred times a day. Add that up across a year and you are paying people to watch a spinner.

Timeouts and errors. Once a query runs past the application's timeout, slow becomes failed. Orders do not save, integrations drop records, and someone re-keys data by hand.

Reports nobody trusts. When a report takes 40 minutes, people stop running it and keep their own spreadsheets. Soon there are three versions of the number.

A cloud bill that keeps growing. In the cloud, inefficiency shows up on the invoice. The usual fix is "bump the tier." That works for a few months, then you bump it again, paying monthly for a problem that could often be fixed once.

Lost sales. A portal that hangs at checkout, or a quote tool that times out with the customer on the phone, costs you the sale. Customers rarely tell you why they left.

Know what "normal" looks like

You cannot manage performance without a baseline. "The database is slow" is a feeling. "The order screen got twice as slow after the last release" is something you can work with.

A useful baseline captures, over time:

• Wait statistics. Every database spends time waiting on something: disk, CPU, memory, locks, the network. Wait stats show where that time goes. SQL Server exposes them through dynamic management views, PostgreSQL shows current wait events in pg_stat_activity (sample them over time to see the pattern), and Oracle records them in its performance views. Different tools, same question: what is the database waiting on?
• Top queries. A short list of queries usually does most of the work. SQL Server's Query Store, PostgreSQL's pg_stat_statements, and Oracle's AWR or Statspack reports rank queries by total time, CPU, and reads. Look at total impact. A 200-millisecond query that runs a million times a day can matter more than a 30-second report that runs once.
• Resource trends. CPU, memory pressure, I/O latency, storage growth, and connection counts at normal load, at peak, and at month-end.

With a baseline, you can see when a problem started, what changed, and whether the fix worked.

Fix the query before you buy hardware

Bigger hardware feels safe. Often it is just expensive. A bad query on a bigger server is still a bad query. And where the database is licensed per core, as SQL Server and Oracle commonly are, more CPUs can raise the licensing bill too.

The real gains usually come from a few places:

Missing indexes. Without a suitable index, the database reads far more than it needs, sometimes a whole table to find a handful of rows. The right index turns that scan into a quick lookup.

Duplicate and unused indexes. The opposite problem is just as common. Every index must be maintained on every insert, update, and delete. Over time, systems pile up overlapping or unused indexes that slow writes, eat storage, and stretch maintenance windows. More is not better.

Bad execution plans. For every query, the database picks a plan: which index, what join order, how much memory. Usually it chooses well. When it does not, the same query goes from fast to painful with no code change.

Parameter sniffing, in plain terms. Many databases build a plan the first time a query runs, based on the values passed in, then reuse it. If the first run asked for a small customer with 10 orders, that plan can be terrible for your largest customer with 100,000. Same query, same plan, very different results. SQL Server calls it parameter sniffing, Oracle has bind variable peeking, and PostgreSQL makes a similar generic-versus-custom plan choice. The symptom is the same everywhere: "It was fast yesterday, and nobody changed anything."

Query and code patterns. Functions wrapped around columns in a WHERE clause, SELECT * pulling unused columns, row-by-row loops that should be set-based, ORM-generated queries nobody has read. These are often small fixes once someone actually looks.

Sometimes the workload really has outgrown the server. Tune first, so that if you do buy more, you know what you are paying to solve.

Maintenance: the unglamorous part that keeps it fast

Statistics. Plan choices depend on statistics, the database's summary of how data is distributed. When they go stale, the optimizer works from an outdated picture. Stale statistics are a common and often overlooked cause of plans that suddenly go bad. Automatic updates help, but on large or fast-changing tables they may run too rarely or sample too little. Check your most important tables.

Index fragmentation, with nuance. Much fragmentation advice dates from spinning disks, where reading pages out of order was expensive. On modern SSD and SAN storage that penalty is much smaller, and rebuilding every index every night can cost more in I/O, log growth, and blocking than it returns. Fragmentation can still matter: low page density wastes memory and I/O, and some large scans and workloads still feel it. In PostgreSQL, the related issue is bloat, managed mainly through vacuum, with an occasional reindex. Maintain indexes based on evidence, not habit. Also note that in SQL Server, a rebuild also refreshes that index's statistics, so sometimes "the rebuild fixed it" was really a statistics fix.

Backups, with tested restores. Not strictly performance, but not optional. A backup you have never restored is a hope. Decide how much data you can afford to lose and how long you can afford to be down, then test restores on a schedule to prove you can meet both. Backups also compete for I/O, so they belong in the performance picture.

Capacity planning: see the wall before you hit it

Your baseline doubles as a forecast. Track trends over months:

• Storage. How fast are data and logs growing? When will the current volume fill up?
• CPU and memory. Is peak usage creeping up? Is the server reading from disk more because the working set no longer fits in memory?
• I/O. Are latency and throughput approaching the limits of your storage or cloud tier?

Then put dollars next to them. Licensing, cloud tiers, and storage pricing tend to move in steps, and the next tier or core count can be a big jump. See it a few months ahead and you can tune, archive, or budget, instead of approving an emergency upgrade at quarter-end.

When to bring in a DBA

Plenty of small and mid-size companies do not need a full-time DBA. You probably need one, even briefly, if:

• Users complain about speed and nobody can say what changed
• Your answer to slowness has been bigger hardware or a higher cloud tier, more than once
• Timeouts or deadlocks show up in application logs
• Reports are run overnight or avoided because they are too slow during the day
• Nobody has tested a restore in the last year, or ever
• The database "just runs" and the person who set it up has left
• A migration, upgrade, or move to the cloud is coming and you have no baseline to compare against

What a health check looks like. It is a short, structured review, not a sales pitch. It typically covers configuration, wait stats and top queries, index health (missing, duplicate, unused), statistics and maintenance jobs, backup and restore coverage, security basics, and growth trends. You should leave with a prioritized list: what is risky, what is slow, what is costing money, and which fixes are cheap versus worth planning.

A short checklist to start this week

• [ ] Write down the three slowest screens or reports your staff complain about
• [ ] Turn on or confirm query tracking (Query Store, pg_stat_statements, or your platform's equivalent)
• [ ] Capture a baseline of wait stats, top queries, CPU, memory, I/O, and storage
• [ ] Check when statistics were last updated on your largest, busiest tables
• [ ] Review index maintenance jobs: are they based on evidence, or rebuilding everything every night?
• [ ] Restore last night's backup to a test server and time it
• [ ] Chart storage growth for the last six to twelve months and project it forward
• [ ] Before the next hardware or cloud-tier upgrade, ask: "Which queries are we paying for?"

Talk to us

If the database is slow, the cloud bill keeps climbing, or nobody is sure the backups would restore, start with a health check. PelicanSoft does database health checks and performance reviews for SQL Server, PostgreSQL, Oracle, and the systems around them, and you get a plain-language list of what to fix first. Twenty minutes to talk it through, no deck tour.

https://pelican-soft.com/contact
Greater Houston, Texas · pelican-soft.com