Database Health Score Calculator
Score a managed database out of 100 from CPU, cache hit ratio, replica lag, connections, IOPS and storage headroom.
Inputs
Below about 99% on OLTP means reads are falling through to storage.
Database Health Score
86/ 100
Grade
B — Good
Performance Subscore
76/ 100
Capacity Subscore
99/ 100
Weakest Dimension
Slow query rate
Operational Risk
Informational
Step by step
Values used
CPU utilisation = 62 %; Buffer cache hit ratio = 98.50 %; Connections used of max_connections = 55 %; Replica lag = 1.20 seconds; IOPS used of provisioned = 48 %; Storage used of allocated = 71 %; Slow queries = 12 per minute
Database Health Score
Each metric becomes a 0–100 subscore against its healthy threshold, then performance = 0.3 CPU + 0.3 cache + 0.2 slow queries + 0.2 lag, capacity = 0.4 storage + 0.35 IOPS + 0.25 connections, and the total is 55% performance plus 45% capacity.
Database Health Score
= 86 / 100
Grade
= B — Good
Performance Subscore
= 76 / 100
Capacity Subscore
= 99 / 100
Weakest Dimension
= Slow query rate
Operational Risk
= Informational
How it works
Each metric is converted to a subscore that stays at 100 until it crosses a healthy threshold and then decays linearly, so a database at 45% CPU scores the same as one at 20% while 90% CPU scores zero on that dimension. The buffer cache hit ratio is scored hardest — the scale runs from 90% to 100% — because on an OLTP workload each percentage point of misses translates into a large multiple of storage reads. A single composite number is what makes fleet reviews possible, but the weakest-dimension output is what makes it actionable: it names the one metric dragging the score down instead of leaving you to guess.
Formula
Database Health Score
Each metric becomes a 0–100 subscore against its healthy threshold, then performance = 0.3 CPU + 0.3 cache + 0.2 slow queries + 0.2 lag, capacity = 0.4 storage + 0.35 IOPS + 0.25 connections, and the total is 55% performance plus 45% capacity.
- threshold
- Point where a metric starts costing score — 50% CPU, 90% cache hits, 60% connections, 70% storage
- performance subscore
- How well the database serves its current load
- capacity subscore
- How much room is left before something has to change
- weakest dimension
- Lowest single subscore — the one worth fixing first
Frequently Asked Questions
How is Database Health Score calculated?
Each metric becomes a 0–100 subscore against its healthy threshold, then performance = 0.3 CPU + 0.3 cache + 0.2 slow queries + 0.2 lag, capacity = 0.4 storage + 0.35 IOPS + 0.25 connections, and the total is 55% performance plus 45% capacity. Each metric is converted to a subscore that stays at 100 until it crosses a healthy threshold and then decays linearly, so a database at 45% CPU scores the same as one at 20% while 90% CPU scores zero on that dimension. The buffer cache hit ratio is scored hardest — the scale runs from 90% to 100% — because on an OLTP workload each percentage point of misses translates into a large multiple of storage reads.
Why does Database Health Score matter?
A single composite number is what makes fleet reviews possible, but the weakest-dimension output is what makes it actionable: it names the one metric dragging the score down instead of leaving you to guess.
What values do I need to enter?
This calculator takes 7 inputs: CPU utilisation, Buffer cache hit ratio, Connections used of max_connections, Replica lag, IOPS used of provisioned, Storage used of allocated, Slow queries. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why is the cache hit ratio scored so aggressively?
Because the relationship is non-linear. Going from 99% to 98% hits doubles the number of reads that must go to storage, and storage reads are three orders of magnitude slower than a buffer-pool hit. On OLTP workloads anything below 99% usually means the instance needs more memory or the working set needs trimming.
Is a score of 100 the goal?
No — a perfect score often means an over-provisioned instance you are paying too much for. Scores in the 75–90 band usually indicate a database that is comfortably provisioned without waste.