Score a managed database out of 100 from CPU, cache hit ratio, replica lag, connections, IOPS and storage headroom.
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.
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.
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.
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.
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.
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.
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.