Database Health Score Calculator
Score a managed database out of 100 from CPU, cache hit ratio, replica lag, connections, IOPS and storage headroom.
About Database Health Score Calculator
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
Worked example
With the default values below, Database Health Score Calculator returns Database Health Score of 86. Change any input above and every figure here is recalculated in your browser.
Inputs used
- CPU utilisationaccepts 0–100 %
- 62 %
- Buffer cache hit ratioaccepts 0–100 %
- 98.5 %
- Connections used of max_connectionsaccepts 0–100 %
- 55 %
- Replica lagaccepts 0–3,600 seconds
- 1.2 seconds
- IOPS used of provisionedaccepts 0–200 %
- 48 %
- Storage used of allocatedaccepts 0–100 %
- 71 %
- Slow queriesaccepts 0–10,000 per minute
- 12 per minute
Results
- 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
- 1Values used
- 2Database Health Score
- 3Database Health Score= 86 / 100
- 4Grade= B — Good
- 5Performance Subscore= 76 / 100
- 6Capacity Subscore= 99 / 100
- 7Weakest Dimension= Slow query rate
- 8Operational Risk= Informational
Assumptions and limits
- The result is derived only from the 7 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to whole numbers, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.