Cost-optimized databases

Pay for the database capacity you actually use: choose the right engine and type, use serverless or on-demand modes for uneven load, offload reads to caches, commit for steady use, and keep backups only as long as you need them.

Choosing a cost-effective database

• Relational data with SQL needs: RDS or Aurora. Key-value access at scale with spiky traffic: DynamoDB, which has no servers to run.
• Open-source engines (MySQL, PostgreSQL, MariaDB, Aurora) avoid commercial license fees; Oracle and SQL Server are license-included or bring-your-own-license.
• Columnar and time-series formats: Analytics over large history is cheaper in a columnar warehouse (Redshift) or as Parquet in S3 queried by Athena than in an OLTP database.
• Aurora I/O-Optimized: A cluster storage option with no per-request I/O charges, which costs less when I/O is a large share of an Aurora bill.

Capacity modes and commitments

• DynamoDB on-demand vs provisioned: On-demand for new or unpredictable traffic. Provisioned with auto scaling for steady, predictable traffic, and reserved capacity for a further discount.
• DynamoDB Standard-IA table class: Lower storage price for tables that are mostly stored and rarely read.
• DynamoDB TTL: Deletes expired items at no cost, so old data stops using storage.
• Aurora Serverless v2: Scales capacity up and down in small steps, for variable or intermittent workloads such as dev databases or apps with idle periods.
• Reserved DB instances and Database Savings Plans: Commit to steady database usage for a lower rate. Database Savings Plans (since December 2025) apply across several AWS database services.
• Stop development RDS instances when not in use (they restart automatically after seven days).

Caching, connections, and replicas

• A cache (ElastiCache or DAX) answers repeated reads from memory, so the database can be smaller or need fewer read capacity units.
• RDS Proxy reuses connections so you don't need a bigger instance just to hold idle connections.
• Read replicas are cheaper than scaling the writer up when only reads are growing; remove replicas nobody uses.

Backups and retention

• Automated RDS backups are kept for 1 to 35 days; manual snapshots stay until you delete them. Match the frequency and retention to the RPO and the policy, not more.
• Export old snapshots to S3 (in Parquet) or move backups to cold storage with AWS Backup for cheap long-term retention.
• Retention policies decide when data can be deleted. Data that no one queries any more belongs in S3, not in a provisioned database.

Migrating to a cheaper engine or location

• AWS DMS moves data with minimal downtime, using change data capture until cutover.
• For a different engine, convert the schema first with DMS Schema Conversion or the AWS Schema Conversion Tool.
• Cost management tools apply here too: tag databases by owner, track them in Cost Explorer, and set Budgets alerts.