Database utilisation analysis

Database utilisation analysis is the practice of measuring how much of your provisioned database capacity is actually consumed across compute, memory, storage, and connections. If your instance is provisioned with 16 vCPUs and averages 4 vCPUs of load, your CPU utilisation is 25 percent. The same logic applies to memory, disk, and the connection pool. The output is a set of percentages that describe how hard the database is working relative to what you are paying for.

The analysis matters because both extremes are expensive in different ways. A database that sits at 10 percent utilisation is burning budget on idle capacity. A database that sits at 95 percent is one query or one traffic spike away from queueing, timeouts, and a customer-facing incident. The useful range is narrow, and it moves as your workload grows, which is why this is an ongoing analysis rather than a one-off measurement.

Utilisation is also a leading indicator. Storage that climbs two percentage points a week tells you when you will run out of disk long before the alert fires. A connection pool creeping toward its ceiling explains the intermittent errors your application team cannot reproduce. Read this way, utilisation analysis is less about cost reporting and more about seeing the failure before it happens.

There is no single utilisation number. A database is a bundle of separate resources that can each saturate independently, so the analysis calculates each one and then reads them together. A server can sit at 20 percent CPU while its connection pool is fully exhausted, and the connection pool is what takes the application down.

1. 1

   CPU utilisation

   Average and peak processor load divided by provisioned vCPUs. High CPU usually points to inefficient queries, missing indexes, or a workload that has outgrown the instance class.

2. 2

   Memory utilisation

   Working memory and buffer cache in use divided by allocated memory. When the cache cannot hold the working set, the database reads from disk far more often and latency climbs sharply.

3. 3

   Storage utilisation

   Disk consumed divided by disk provisioned. Track the growth rate, not just the level, so you can forecast the date you run out rather than reacting when you hit it.

4. 4

   Connection utilisation

   Active and idle connections divided by the connection limit. Pools fill quietly during peak load and then reject new requests, which surfaces in the application as errors with no obvious database cause.

5. 5

   IOPS and throughput utilisation

   Read and write operations against the provisioned IOPS ceiling. On cloud databases this is often the real bottleneck because IOPS is metered separately from CPU and storage.

Tie these together by reading them as a set over the same window. The headline question is which resource saturates first, because that resource determines both your reliability ceiling and your next provisioning decision. A database at 30 percent CPU, 85 percent memory, and 95 percent IOPS is an IOPS problem, and adding CPU would waste money while fixing nothing.

A metric tree decomposes database utilisation into the resources that make it up and then traces each resource back to the workload and the team that drives it. This turns a vague reliability worry into a specific, owned question.

The first level splits utilisation into CPU, memory, storage, connections, and IOPS. Each branch then decomposes into the things that actually move it. CPU breaks down into query efficiency, index coverage, and concurrent request volume. Storage breaks down into data growth, retention policy, and bloat from unvacuumed tables. Connections break down into pool sizing, leaked connections, and per-request hold time.

This structure lets you diagnose precisely rather than over-provisioning by reflex. If utilisation is rising, the tree tells you whether it is more traffic, a slow query that shipped last week, or a retention policy that quietly stopped running. Each diagnosis points at a different fix owned by a different person.

Healthy utilisation ranges depend on the resource and on how spiky the workload is. The targets below are sustained peak figures, because capacity has to absorb the busy period, not the quiet overnight average. A bursty consumer app needs more headroom than a steady internal reporting database.

Treat these as starting points, not absolutes. A database fronted by a connection pooler can run hotter on connections safely. A workload with predictable, gentle traffic can run CPU higher than a spiky one. The benchmark that matters most is your own trend: utilisation that climbs steadily week over week is the signal to act, whatever the absolute level.

Improving utilisation means pushing each resource toward its healthy band, not simply driving every number down. The goal is enough headroom to survive the peak without paying for capacity that never gets used. The biggest gains usually come from the workload, not the hardware.

The metric tree approach starts by finding which resource saturates first, because that is the constraint that caps both reliability and growth. Improving anything else moves a number that was never the problem.

KPI Tree lets you model this by connecting each utilisation branch to the team and the action that influences it. Engineering owns query efficiency and index coverage. Platform owns instance sizing and IOPS provisioning. Data owns retention and growth. With RACI ownership on every node, the accountable owner is named, and when a branch crosses its threshold the alert goes to that person rather than the whole channel. The verified impact loop then checks whether the index that shipped actually pulled CPU back into its healthy band, so you know the fix worked rather than assuming it did.

1. 1

   Watching averages and missing peaks

   A database that averages 40 percent CPU can saturate every weekday morning. Capacity has to cover the peak, so analyse peak and average together or you will be blind to the moment that actually breaks.

2. 2

   Tracking one resource and ignoring the rest

   Teams often watch CPU and forget connections and IOPS. A database can sit comfortably on compute while the connection pool is the thing rejecting requests and taking the application down.

3. 3

   Reacting to storage level instead of growth rate

   Knowing disk is at 70 percent is far less useful than knowing it climbs two points a week. The growth rate tells you the date you run out, which is the number you can plan against.

4. 4

   Over-provisioning to feel safe

   Doubling the instance to silence an alert hides the real cause and doubles the bill. Most utilisation spikes are a query or an index problem, and the bigger instance just postpones the same conversation at higher cost.

5. 5

   Measuring utilisation without owners

   A utilisation dashboard nobody owns gets ignored until it turns red. Without an accountable owner on each resource, the analysis describes the problem but never closes it.