This inefficiency occurs when BigQuery slot reservations are sized for peak or anticipated demand but are not adjusted as workloads evolve. When actual query concurrency or complexity is lower than expected, a portion of the reserved slots remains idle. Because slot reservations are billed independently of usage, underutilized capacity results in sustained waste even while on-demand query costs elsewhere may continue.

This commonly happens when reservations are created during migrations, one-time analytical initiatives, or early scaling phases and are not revisited once usage stabilizes.

‍

This inefficiency occurs when an RDS database instance is deleted but its manual snapshots or retained backups remain. Unlike automated backups tied to a live instance, these backups persist independently and continue generating storage costs despite no longer supporting any active database. This is distinct from excessive retention on active databases and typically arises from incomplete cleanup during decommissioning.

This inefficiency occurs when Azure SQL Managed Instances continue running on legacy General Purpose or Business Critical tiers despite the availability of the next-gen General Purpose tier. The newer tier enables more granular scaling of vCPU, memory, and storage, allowing workloads to better match actual resource needs. In many cases, workloads running on Business Critical—or overprovisioned legacy General Purpose—do not require the premium performance or architecture of those tiers and could achieve equivalent outcomes at lower cost by moving to next-gen General Purpose.

This inefficiency occurs when ElastiCache clusters continue running engine versions that have moved into extended support. While the service remains functional, AWS charges an ongoing premium for extended support that provides no added performance or capability. These costs are typically avoidable by upgrading to a version within standard support.

This inefficiency occurs when Amazon Aurora database clusters are intentionally stopped to avoid compute costs but are automatically restarted by the service after the maximum allowed stop period. Once restarted, re-started database instances begin accruing instance-hour charges even if the database is not needed.

Because Aurora does not provide native lifecycle controls to keep clusters stopped indefinitely, this behavior can result in recurring, unintended compute spend—particularly in non-production, seasonal, or infrequently accessed environments where clusters are stopped and forgotten.

This inefficiency occurs when automated Cloud SQL backups are retained longer than required by recovery objectives or governance needs. Because backups accumulate over the retention window (and can grow quickly for high-change databases), excessive retention drives ongoing backup storage charges without improving practical recoverability.

Serverless is attractive for variable or idle workloads, but it can become more expensive than Provisioned compute when database activity is high for long portions of the day. As active time increases, per-second compute accumulation approaches—or exceeds—the fixed monthly cost of a Provisioned tier. This inefficiency arises when teams adopt Serverless as a default without assessing workload patterns. Databases with steady demand, predictable traffic, or long active periods often operate more cost-effectively on Provisioned compute. The economic break-even point depends on workload activity, and when that threshold is consistently exceeded, Provisioned becomes the more efficient option.

Databases deployed on Provisioned compute incur continuous hourly charges even when workload demand is low. For databases that are active only briefly within an hour, or for limited hours per month, Serverless can provide significantly lower cost because it bills only for active compute time. The economic break-even point between Provisioned and Serverless depends on workload activity patterns. If monthly active time falls *below* the conceptual break-even range, Serverless is more cost-effective. If active time regularly exceeds that range, Provisioned may be more appropriate. This inefficiency typically appears when teams default to Provisioned compute without evaluating workload behavior over time.

Azure Hybrid Benefit allows organizations to apply existing SQL Server licenses with Software Assurance or qualifying subscriptions to Azure SQL Databases. When this configuration is missed or not enforced, workloads continue to incur license-inclusive costs despite license ownership. This oversight often occurs in environments where licensing governance is decentralized or when databases are provisioned manually without applying existing entitlements. Across multiple databases or elastic pools, these duplicated license costs can accumulate substantially over time.

Aurora Serverless is designed for workloads with unpredictable or intermittent usage patterns that benefit from automatic scaling. However, when used for databases with constant load, the service’s elasticity offers little advantage and adds cost overhead. Serverless instances run continuously in steady workloads, resulting in persistent ACU billing at a higher effective rate than a provisioned cluster of similar size. In addition, Serverless configurations cannot use Reserved Instances or Savings Plans, missing out on predictable cost reductions available to provisioned Aurora.