Cutting managed database costs without breaking SLOs

WHAT THIS TESTS The interviewer wants to see that you attack the cost drivers, not just the instance size, and that every saving is checked against your performance SLOs.

A GOOD ANSWER COVERS First measure where money goes: compute, storage, provisioned IOPS, backups, and data transfer. On compute and connections, introduce a connection pooler such as PgBouncer so thousands of app connections map to a small server-side pool, letting you avoid sizing memory for idle connections. On indexes, drop unused and duplicate indexes that bloat storage and slow writes, and add missing ones so queries do less IO and CPU, directly shrinking the instance you need. Offload read-heavy analytics and reporting onto read replicas or a cheaper analytics store so the primary stays small. Use partitioning to prune queries and to age out cold partitions into cheaper object storage, and set retention so you are not paying premium IOPS storage for years of stale rows. Right-size provisioned IOPS and storage type to actual utilization, and apply reserved or committed-use pricing for steady baseline capacity while keeping autoscaling for spikes.

COMMON WRONG ANSWERS Only downsizing the instance, which often just trades the bill for SLO violations. Adding indexes everywhere, which raises storage and write cost. Ignoring storage and IOPS, which can dominate the bill on write-heavy systems.

LIKELY FOLLOW-UPS How do you find unused indexes safely? When does a read replica not help? How do you validate a change did not regress p99 latency?

ONE CONCRETE EXAMPLE An app sized a huge instance to handle five thousand mostly idle connections. Adding PgBouncer cut required memory enough to drop two instance tiers, removing six redundant indexes shrank storage and sped writes, and moving reporting to a read replica kept p99 within SLO while lowering the monthly bill substantially.