Stakeholder Basics

SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;
SELECT pg_size_pretty(sum(pg_total_relation_size(relid))) FROM pg_stat_user_tables;

SELECT date_trunc('month', now()) AS month,
       pg_size_pretty(pg_database_size('app')) AS size;
-- Compare to last month export in spreadsheet

Checkout p95 rose from 120ms to 800ms (database slice 600ms).
Conversion dropped 0.4% = ~$220k/month modeled revenue.
Fix: index + pool tuning, 2 engineering days, no schema break.

SELECT query, mean_exec_time, calls
FROM pg_stat_statements
WHERE query LIKE '%orders%'
ORDER BY mean_exec_time * calls DESC
LIMIT 5;

## Option A: Sunday 03:00 UTC window
- User impact: up to 45s write delay on billing API
- Benefit: validate FK on 80M payments (correctness)
- Skip risk: continued orphan rows in refunds
 
## Option B: Defer 6 weeks
- User impact: none now
- Risk: finance reconciliation errors accumulate

SELECT application_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)) AS lag_bytes
FROM pg_stat_replication;

"We need pgaudit on payments schema" →
"Regulators expect immutable payment access logs; gap is audit finding severity High."

# Database Health - July 2026
**Status:** Yellow (disk growth)
**User impact last month:** 12 min checkout degradation (Sev-2)
**Spend:** $48k/mo RDS + $6k observability
**Ask:** Approve Q3 archive project ($40k eng, saves $8k/mo storage)

EOL: PostgreSQL 17 community support ends 2029; vendor extended 1 year.
Risk of defer: unpatched CVE exposure + hiring friction.
Proposal: upgrade week 2 after peak season; 4h planned budget spend.

## Customer-safe summary (Sev-2)
Between 14:22-14:48 UTC some customers saw slow checkout.
No data was lost. Root cause: long database transaction from deploy.
Prevention: timeout policy + training (in progress).