Usage.ai, the New York-based cloud cost optimization platform, dropped a significant update this week: full automation support for AWS Database Savings Plans across all 10 eligible services is now live. The announcement, made June 16, 2026, comes on the heels of AWS expanding DSP eligibility to OpenSearch Service and Neptune Analytics back in March—meaning Usage.ai had fresh ground to cover just months after the program matured.

All 10 Services Now Covered

The platform handles Amazon RDS (Gen 7+ provisioned instances), Aurora (Gen 7+, Serverless v2, DSQL), DynamoDB (on-demand and provisioned throughput), ElastiCache (Valkey engine only), DocumentDB (Gen 7+, Serverless), Neptune (Gen 7+, Serverless, Analytics), Keyspaces, Timestream for InfluxDB, OpenSearch Service (Serverless, Gen 7+), and AWS Database Migration Service. That's a wide surface area—and the eligibility rules differ meaningfully across each service, from instance generation requirements to which storage tiers qualify.

How Usage.ai Handles the Full DSP Lifecycle

The platform automates in five stages: pulling Cost and Usage Report data to identify eligible spend (separating it from RI-eligible spend), calculating the 60-day hourly floor for right-sized commitment sizing, purchasing through billing-layer access with immediate activation, monitoring utilization on a 24-hour refresh cycle instead of AWS Cost Explorer's 72+ hour lag, and providing cashback on underutilized commitments. The fee structure is straightforward—percentage of realized savings only, no upfront costs to the customer.

Key Facts About Database Savings Plans

These aren't your standard Compute Savings Plans. DSP has a hard 1-year term with No Upfront payment only—no All Upfront or Partial Upfront options exist here. Maximum savings reach 35% for serverless workloads like Aurora Serverless v2 and Neptune Analytics, 20% for most provisioned instances, 18% for on-demand throughput (DynamoDB, Keyspaces), and 12% for their provisioned capacity counterparts. AWS applies DSP after Reserved Instances in the discount waterfall, so you can't stack them on the same workload in the same billing hour.

Recommended Order of Operations Before Committing

Usage.ai's guidance is clear: right-size based on CPU and memory utilization first, migrate to current-generation instances (Gen 7+ for RDS/Aurora; Valkey engine for ElastiCache since older generations remain RI-only), evaluate storage configuration carefully—Aurora and DocumentDB's I/O-Optimized option carries different cost implications depending on actual I/O consumption—and only then purchase DSP commitments against the confirmed, right-sized spend floor. Buying before completing these steps locks in commitments on oversized or ineligible infrastructure.

Leadership Perspective

CEO Kaveh Khorram framed the broader context: "FinOps started with EC2. It matured into Savings Plans and Reserved Instances across compute. The next phase is database and it's more complex because the eligibility rules, the instance families, and the discount waterfall all behave differently across 10 services." He added that teams which balance engineering judgment with financial discipline are where cloud economics get won or lost.

Why This Matters for Engineering Teams

The operational complexity here isn't trivial. Ten services with different eligibility requirements, varying savings rates tied to workload type, instance generation gates, storage tier implications, and a discount waterfall that requires careful sequencing alongside existing Reserved Instances—this is exactly the kind of multidimensional problem that creates FinOps debt in growing organizations. Usage.ai's approach automates the analysis work that most teams either skip or do poorly, which means fewer over-committed dollars sitting idle on services that got migrated or downsized.

Key Takeaways

  • DSP term is locked at 1-year with No Upfront payment only—no flexibility in commitment structure
  • Serverless workloads (Aurora Serverless v2, Neptune Analytics, DocumentDB Serverless) hit up to 35% savings—highest tier available
  • ElastiCache requires Valkey engine; standard Redis OSS and Memcached remain RI-only
  • DynamoDB DSP cannot stack with reserved capacity on the same table
  • Usage.ai's 24-hour monitoring cycle catches utilization drops faster than AWS Cost Explorer's delayed reporting

The Bottom Line

This is solid automation work on a genuinely complex problem. If your organization runs meaningful database workloads on AWS and isn't actively managing DSP commitments, you're leaving real money on the table—and probably over-committed on services that got refactored six months ago without anyone adjusting the billing layer. Usage.ai's fee structure aligns incentives properly: they only win when you save.