Databases Posts

Database costs are the second largest line item on most AWS bills I review, right behind compute. The problem is that RDS and Aurora pricing has enough moving parts to keep teams overspending for years without realizing it. Instance hours, storage, I/O operations, backup retention, snapshots, data transfer, Extended Support surcharges. Each component has its own optimization lever, and most teams only pull one or two of them. After years of running production databases on AWS and auditing bills across dozens of accounts, I have a reliable playbook for cutting RDS and Aurora spend by 40-65% without sacrificing availability or performance. This article lays out that playbook: every strategy, the math behind it, and the operational tradeoffs you need to understand before applying each one.

Every distributed system I have built forced a conversation about consistency before it forced a conversation about performance. Sometimes that conversation happened during design. More often it happened at 3 AM when a customer reported stale data, a checkout double-charged, or a dashboard showed a record that had been deleted twenty seconds earlier. The CAP theorem gets referenced in every system design interview and every architecture document, yet most teams still get caught off guard by what it actually means in production. The theorem itself is simple. Living with its consequences is where the engineering happens.

Every production architecture conversation I've had in the last five years eventually lands on the same question: can we go active/active across regions? The answer with Aurora has historically been "sort of, with significant caveats." Aurora Global Database gives you cross-region reads and fast failover. Write forwarding lets secondary regions send writes to the primary. Aurora DSQL promises genuine multi-region active/active with strong consistency. Each of these represents a different point on the spectrum between "one region writes, everyone else reads" and "any region writes, strong consistency everywhere." I've deployed all of them. The operational reality of each is more nuanced than the marketing suggests.

Every relational database argument eventually becomes a religion debate. I have no interest in that. What I care about is how these engines behave under load, where they break, and what happens when you deploy them on Aurora's distributed storage layer. After running both MySQL and PostgreSQL in production on Aurora across dozens of services, the differences that actually matter have little to do with SQL syntax preferences. They live in storage engine internals, MVCC implementation, connection handling, and the operational failure modes that surface at 3 AM when your on-call phone goes off.

DynamoDB sits at the center of more AWS architectures than any other database service. I've used it for everything from mobile backends handling millions of daily active users to event-sourced systems processing tens of thousands of writes per second. Most teams treat it as a simple key-value store, plug it in, and move on. That works until they hit a hot partition at 3 AM, discover their GSI is throttling independently of the base table, or realize their on-demand table costs three times what provisioned capacity would have. After years of running DynamoDB at scale, I've accumulated enough operational scars to fill this reference. Patterns, trade-offs, cost traps, and the internal mechanics that explain why DynamoDB behaves the way it does.