A SaaS provider runs DynamoDB with spiky traffic, Aurora PostgreSQL with steady baseline plus high I/O, and RDS MySQL dev instances idle nights. They need lower bills without code changes. Which database cost optimization matches capacity models to each workload?

The correct design aligns price to use without code changes because DynamoDB on-demand bills per request and absorbs instant spikes without capacity planning or throttling, while Aurora I/O-Optimized eliminates per-million I/O charges that dominate high-I/O PostgreSQL and reserved instances discount the steady baseline compute, and scheduled stopping of idle RDS MySQL dev instances removes night compute cost while Database Savings Plans (spend-based commitments covering RDS and Aurora) lower the remaining daytime rate. The provisioned autoscaling approach fails on burst handling because scaling follows CloudWatch metrics with delay and needs headroom, so sharp spikes either throttle or force expensive overprovisioning unlike true on-demand. The Serverless v2 approach fails on I/O cost because it provides compute elasticity for variable loads yet keeps standard I/O billing with a premium per capacity unit, so a steady high-I/O baseline costs more than I/O-Optimized with commitments. The always-on Savings Plans approach fails on idle waste because discounts only reduce the rate for hours consumed and cannot eliminate consumption, so running dev databases overnight still accrues avoidable charges. For exams map spiky to on-demand, steady plus high I/O to I/O-Optimized with commitments, and idle to stopping rather than discounting alone, and in practice confirm with Cost Explorer plus DynamoDB throttles, Aurora IOPS trends, and RDS stop tags before committing.