Enterprise strategies for reducing database costs 40–70% across AWS RDS/Aurora, Azure SQL/Cosmos DB, and GCP BigQuery/Cloud SQL. Includes reserved capacity analysis, rightsizing methodology, and procurement negotiation tactics.
Database services consistently rank as one of the largest line items in enterprise cloud bills — often 15–25% of total spend. Unlike compute, where serverless and spot instances offer aggressive savings levers, databases run persistent, stateful workloads that are harder to interrupt. This creates a cost profile that compounds over time without active management.
The core problem is provisioning inertia. DBAs typically size databases for peak load plus a safety buffer, then never revisit those choices. In cloud environments, that means paying for db.r6g.4xlarge instances that consistently run at 12% CPU utilisation. Add Multi-AZ standby instances, automated backups, and I/O throughput charges, and it's easy to understand why database costs balloon.
This guide covers the cloud cost optimization strategies that deliver the fastest ROI specifically for database workloads — across every major hyperscaler. For broader cost reduction context, see also our guides on AWS cost optimization, Azure cost management, and GCP cost optimization.
Enterprises that conduct a structured database cost review typically find 35–50% of database spend is recoverable within 90 days without any application changes. The majority comes from instance rightsizing, reserved capacity, and eliminating idle dev/test databases.
Amazon RDS and Aurora together account for the majority of AWS database spend. RDS supports MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server on managed infrastructure. Aurora is AWS's proprietary engine offering MySQL and PostgreSQL compatibility with higher performance and a distributed storage model.
The most impactful RDS optimisation lever is instance class selection. Many enterprises deploy db.r5 or db.r6g memory-optimised instances by default, even for workloads that are primarily CPU-bound or storage-bound. Moving to the correct instance family can reduce costs 20–35% before any other changes.
RDS Reserved Instances offer 1-year and 3-year commitments with savings of 36–69% versus On-Demand pricing. Unlike EC2 Reserved Instances, RDS RIs are scoped to a specific instance class, region, and database engine — with no instance size flexibility within a family. This requires accurate sizing before committing.
| RDS Instance Class | On-Demand ($/hr) | 1-yr Reserved | 3-yr Reserved | Best For |
|---|---|---|---|---|
| db.t3.medium | $0.068 | $0.044 (35%↓) | $0.028 (59%↓) | Dev/test, low traffic |
| db.m6g.large | $0.145 | $0.092 (37%↓) | $0.058 (60%↓) | General purpose |
| db.r6g.xlarge | $0.480 | $0.298 (38%↓) | $0.192 (60%↓) | Memory-intensive |
| db.r6g.4xlarge | $1.920 | $1.190 (38%↓) | $0.768 (60%↓) | High-throughput OLTP |
| db.x2g.8xlarge | $13.338 | $8.209 (38%↓) | $5.254 (61%↓) | In-memory / SAP HANA |
Aurora offers an important pricing difference from RDS: storage is billed separately from compute and scales automatically in 10GB increments. This eliminates over-provisioning storage upfront. However, Aurora charges I/O per request (for Aurora Standard), which can be expensive for write-heavy workloads. Aurora I/O-Optimised pricing eliminates per-request I/O charges in exchange for a higher compute/storage rate — typically cost-effective once I/O exceeds 25% of Aurora costs.
Aurora Serverless v2 scales compute capacity in 0.5 ACU increments from 0.5 to 256 ACUs, with pricing per ACU-hour (~$0.12/ACU-hr). This is compelling for variable workloads, but requires careful analysis against provisioned pricing for sustained loads.
Aurora Serverless v2 is typically more expensive than a Reserved provisioned instance once utilisation exceeds 40–50% of capacity for sustained periods. The breakeven point depends on the fluctuation pattern: highly variable workloads with long idle periods favour Serverless, while workloads with consistent moderate load should use provisioned plus Reserved Instances.
Teams migrating to Aurora Serverless v2 assuming it's "always cheaper" than provisioned often see bills increase 30–50% for steady-state OLTP workloads. Model actual ACU consumption from CloudWatch metrics before migrating.
Azure SQL Database, Azure SQL Managed Instance, and Azure Database for PostgreSQL/MySQL are Microsoft's primary managed database offerings. Pricing models span DTU-based (for legacy tiers), vCore-based (for General Purpose, Business Critical, and Hyperscale), and serverless vCore tiers.
The Azure Hybrid Benefit (AHB) is the most impactful savings lever for Azure SQL. Customers with SQL Server Enterprise or Standard licences with active Software Assurance can apply those licences to Azure SQL, saving 40–55% on licensing costs. Combined with Reserved Capacity (1-yr or 3-yr), total savings can reach 65–75% versus pay-as-you-go. See our detailed Azure Hybrid Benefit guide for stacking strategies.
| Azure SQL Tier | PAYG ($/vCore/hr) | AHB Applied | AHB + 1yr RI | AHB + 3yr RI |
|---|---|---|---|---|
| General Purpose (4 vCore) | $0.726 | $0.399 (45%↓) | $0.290 (60%↓) | $0.218 (70%↓) |
| Business Critical (4 vCore) | $2.194 | $1.210 (45%↓) | $0.877 (60%↓) | $0.658 (70%↓) |
| Hyperscale (4 vCore) | $0.797 | $0.438 (45%↓) | $0.319 (60%↓) | $0.239 (70%↓) |
| SQL Managed Instance (8 vCore) | $1.452 | $0.799 (45%↓) | $0.580 (60%↓) | $0.436 (70%↓) |
Azure SQL Hyperscale is worth evaluating for large databases (1TB+) with variable storage needs. It decouples compute from storage and offers independent scaling, with secondary read replicas available at a fraction of primary compute cost. For read-heavy analytical workloads, adding a Hyperscale read replica instead of scaling primary compute can reduce costs 40–60%.
Azure Cosmos DB is one of the most expensive cloud database services per unit of throughput, and one of the most frequently over-provisioned. The provisioned throughput model bills per 100 Request Units per second (RU/s), charged hourly regardless of actual consumption. Many enterprises provision for peak and pay for idle capacity around the clock.
The primary cost levers for Cosmos DB are autoscale provisioned throughput, serverless mode, and multi-region write configuration. Autoscale scales throughput between 10% of the max RU/s provisioned and the max, billing only for the highest RU/s used in each hourly window. This alone can reduce Cosmos DB costs 30–50% for workloads with significant diurnal variation.
Cosmos DB Serverless (GA since 2022) charges per actual RU consumed with no minimum. At low to moderate traffic levels it is dramatically cheaper than provisioned throughput, but has limitations: maximum 50GB per container, no multi-region write, and per-RU cost is 3–5× higher than provisioned per-RU at sustained scale. Model the crossover point carefully.
Multi-region write replication multiplies throughput costs by the number of write regions. A 10,000 RU/s database across 3 write regions costs the same as 30,000 RU/s in a single region. Most enterprises using multi-region write for disaster recovery should switch to single-region write with cross-region read replicas unless they genuinely need active-active writes globally.
BigQuery uses two pricing models: on-demand (per TB scanned) and capacity/flat-rate (reservations). On-demand pricing at $6.25/TB is intuitive but becomes expensive as query volumes scale. The optimisation goal is maximising data pruning (reducing bytes scanned) while choosing the right commitment model.
The most impactful BigQuery optimisation is partition pruning and clustering. Partitioning tables by date or another column means queries with appropriate WHERE clauses only scan relevant partitions, reducing scanned bytes by 80–95% for time-series workloads. Clustering within partitions further reduces scan scope for filtered queries.
| BigQuery Pricing Model | Unit | Price | Best For |
|---|---|---|---|
| On-Demand | Per TB scanned | $6.25/TB | Unpredictable, low volume |
| Standard Edition (slots) | Per slot-hour | $0.04/slot-hr | Flexible capacity, auto-scaling |
| Enterprise Edition | Per slot-hour | $0.06/slot-hr | CMEK, advanced security needs |
| 1-Year Reservation | Per slot-hr committed | ~30% off Standard | Predictable high-volume workloads |
| 3-Year Reservation | Per slot-hr committed | ~52% off Standard | Stable enterprise analytical workloads |
BigQuery flat-rate reservations (now branded as Standard/Enterprise editions with slot commitments) make economic sense once on-demand spend exceeds approximately $10,000–$15,000/month. At that level, slot commitments typically deliver 30–50% savings. The key variable is slot utilisation — reservations are best shared across multiple projects/teams via reservation assignments to maximise slot usage throughout the day.
Google Cloud SQL mirrors RDS in pricing structure — compute instances, storage, and I/O are billed separately. Cloud SQL Committed Use Discounts (CUDs) offer 1-year and 3-year options with 25–52% discounts for MySQL, PostgreSQL, and SQL Server instances. Unlike Compute Engine CUDs, Cloud SQL CUDs are instance-type specific.
Cloud Spanner is Google's globally distributed relational database, priced per processing unit (1,000 PUs = 1 node) plus storage. At $0.90/hour per node and $0.30/GB/month for storage, Spanner is expensive for most workloads. Cost optimisation focuses on: minimising node count with proper schema design, using regional (vs multi-regional) configurations where global consistency isn't required, and auditing idle Spanner instances which are frequent due to team turnover.
Reserved capacity is the single highest-ROI lever for database cost reduction — but it requires confidence in sizing. The strategic approach is to purchase reservations based on your measured steady-state utilisation (not peak), leaving peak capacity as on-demand. A common framework:
One critical nuance for AWS: RDS Reserved Instances do not have instance size flexibility (unlike EC2). An RDS RI for db.r6g.4xlarge cannot be applied to two db.r6g.2xlarge instances. Purchase RIs at the exact instance class you plan to run. For more on AWS reservation strategy, see our Reserved Instances vs Savings Plans comparison and Azure Reserved Instances guide.
Database rightsizing is more conservative than compute rightsizing — abrupt changes to running databases carry higher risk than adjusting an EC2 instance. A structured approach:
Phase 1 — Metrics collection (4 weeks): Capture CPU, memory, IOPS, connections, and storage growth for all databases. Use CloudWatch, Azure Monitor, or Cloud Monitoring. Flag instances where peak CPU never exceeds 30% and average CPU stays below 15%.
Phase 2 — Tiering analysis: Group databases by workload type (OLTP, analytics, reporting, archive). Databases in the wrong family (e.g., memory-optimised instances for CPU-bound OLTP) are immediate rightsizing candidates.
Phase 3 — Staged testing: Downsize dev/test instances first. Validate query performance at the new class for at least two weeks before changing production. Most teams find query latency is unaffected when moving between instance classes in the same family (e.g., db.r6g.4xlarge → db.r6g.2xlarge) if average CPU remains below 25%.
Phase 4 — Production changes: Schedule changes during maintenance windows. Use RDS modify with apply immediately = false to defer changes to the next maintenance window. Azure SQL and Cloud SQL support online scale operations with minimal downtime.
Dev, test, staging, and QA databases are often identical to production in spec — and run 24/7. Audits consistently find that 40–60% of an enterprise's database instances serve non-production purposes. Scheduled stop/start automation delivers immediate savings with no risk to production.
AWS RDS supports Stop and Start actions that stop an instance for up to 7 consecutive days (after which it auto-restarts). Automating stop/start using AWS Lambda and EventBridge for a 10-hour work day schedule (Monday–Friday, 8am–6pm) reduces runtime from 168 hours/week to 50 hours — a 70% reduction. Azure SQL and Cloud SQL have equivalent mechanisms.
A single db.r6g.4xlarge RDS instance running 24/7 at on-demand pricing costs ~$1,382/month. On a 10hr/day weekday schedule, that drops to ~$411/month — $970 saved per instance per month before applying Reserved Instance pricing.
Multi-AZ deployments in RDS double compute and storage costs by maintaining a synchronous standby replica in a separate Availability Zone. This is the right choice for production databases where RPO/RTO requirements justify the cost — but is commonly applied to dev/test and low-criticality workloads where it provides no real benefit.
Auditing Multi-AZ usage across all databases and disabling it for non-production or non-critical workloads typically saves 40–50% on affected instances immediately. For production databases where Multi-AZ is genuinely needed, consider Aurora's alternative: Aurora clusters maintain multiple copies of data across 3 AZs in storage automatically, and a single Aurora Reader instance provides failover capability at ~50% of the cost of a full Multi-AZ standby.
Storage costs are often overlooked in database optimisation but can represent 20–40% of total database spend, particularly for Aurora (I/O charges), RDS with heavy write workloads, and Cosmos DB (request unit consumption for storage operations).
Key storage optimisation actions include:
Managed database services (RDS, Azure SQL, Cloud SQL) include patching, backup, monitoring, and Multi-AZ management in their pricing. Self-managed databases on EC2/VMs are cheaper in raw compute cost but add operational overhead, licensing complexity, and engineering time.
For SQL Server and Oracle workloads, self-managed on EC2 with Bring-Your-Own-License (BYOL) can be 30–50% cheaper than RDS for the same instance size — but requires managing OS patches, database upgrades, and backup infrastructure. The economics favour self-managed when you have a dedicated DBA team and existing perpetual licences.
Third-party support options like Rimini Street for Oracle can reduce ongoing support costs 50% while the database runs on cloud infrastructure — worth modelling for large Oracle on RDS deployments. For SQL Server, see our SQL Server licensing guide for per-core vs Server+CAL analysis.
Is database spend your largest cloud cost category?
Our specialists have benchmarked database spend across 500+ enterprise cloud environments. Get matched with the right expert for your platform.