A good cost review is not a tool that prints a number. It is a sequence: get the right access, look at nine areas in order, quantify each opportunity with its own math, and rank the fixes by impact, effort, and risk. Here is the method, end to end.

Problem

Most database “cost reviews” are either a vendor dashboard screenshot or a one-off “make it cheaper” sprint. Neither produces something a team can act on with confidence. The first lacks engineering judgment; the second lacks reliability guardrails and tends to trade away durability for a short-term saving. A real review is structured, evidence-based, and sequenced.

Why it matters financially

Database spend grows quietly and compounds. The cost of not reviewing is two-sided: you keep paying for waste (oversized instances, idle replicas, bloat), and you carry unmeasured reliability risk (untested failover, unverified restores) that turns into an expensive incident at the worst time. A structured review surfaces both — and, just as important, it produces a prioritized plan, so the savings actually get implemented instead of dying in a backlog.

Technical root causes (why bills drift)

  • Instances sized for a launch and never revisited.
  • Storage and I/O charges that grow without anyone watching the trend.
  • Replicas added “to be safe” that never receive read traffic.
  • Bloat and unused indexes inflating storage and write cost.
  • Observability too thin to even see where the money goes.

The method, in order

0. Get read-only access and a metrics window. Without it you are guessing. A replica, snapshot, or read-only role plus 2–4 weeks of metrics is enough. Sign a mutual NDA; never take write access for a review.

Then work the nine areas, in this order (cheap-to-see first, riskier-to-fix later):

  1. Cost — instance sizing vs utilization, idle/non-prod, pricing model, storage/I/O drivers.
  2. Performance — top queries (pg_stat_statements), index effectiveness, connections, cache hit ratio.
  3. Reliability — failover tested, HA posture, single points of failure, headroom.
  4. Storage — bloat/dead tuples, growth trend, retention/archival.
  5. Replication — replica utilization, lag visibility, read/write routing.
  6. Backup & recovery — backups exist, restores tested, PITR/RPO understood.
  7. Observability — metrics coverage, query-level insight, alerting on leading indicators.
  8. Security — encryption, least-privilege, audit/change visibility.
  9. Automation — which toil could be automated to cut risk and cost.

Quantifying an opportunity honestly

This is where reviews earn or lose trust. For each opportunity:

  • Show the math. “Writer at 14% peak CPU over 30 days; one class down ≈ 50% of compute cost ≈ $X/month.”
  • Give a range, not a point. Real savings depend on validation and execution.
  • Never promise a percentage before you’ve looked. Be wary of anyone who does.
  • Flag the reliability tradeoff of every cost cut explicitly.

Prioritizing: impact × effort × risk

Score each finding on impact (cost or reliability), effort to fix, and risk of the fix. The plan writes itself when you sort by those three: low-risk high-impact first, risky changes later with guardrails.

Building the 30/60/90 plan

  • First 30 days — instrument & capture low-risk wins: enable statement stats and slow-query logging, add leading-indicator alerts, remove clearly idle resources, confirm restores work.
  • Days 31–60 — right-size & reduce structural waste: act on sizing and pricing findings backed by data, fix replica routing, begin bloat/index cleanup.
  • Days 61–90 — harden & sustain: failover testing, pooling, automation of toil, and a baseline so you can prove the changes worked.

Review checklist

Use the full 30-Point Database Cost Review Checklist to run this yourself. It covers all nine areas plus the planning step.

Example findings

(Illustrative.) A typical first review surfaces: one oversized non-prod-hours pattern, one or two idle replicas, a handful of unused indexes, a top-three I/O query missing an index, and — almost always — at least one untested restore or failover. The cost items pay for the review; the reliability items are why you do it before an incident.

Actions to take

  1. Secure read-only access and a metrics export.
  2. Walk the nine areas in order; cite evidence for every finding.
  3. Quantify each opportunity with its own math and a range.
  4. Rank by impact × effort × risk and write the 30/60/90 plan.
  5. Re-measure after changes to confirm they landed.

Want this run for your environment by a senior engineer? AKS delivers a Database Cost & Reliability Review with prioritized findings and a 30/60/90 plan — read-only, evidence-driven, no overpromised savings. See the full Acme SaaS sample report for the exact format.