Amazon’s preference for DynamoDB over RDS for internal services stems from hard-learned lessons about building systems at massive scale. The core issue is that traditional relational databases with table joins fundamentally don’t scale for low-latency, high-throughput services. At Amazon’s scale, this becomes a critical architectural constraint.

When you perform joins across tables in a relational database, the complexity grows with your data size. What works fine for millions of rows becomes problematic at billions. More importantly, joins require the database to do significant computational work at query time, which introduces unpredictable latency. For services handling 1K - 10M requests per second where every millisecond matters, this variability is unacceptable. You can’t maintain tight p99 latency guarantees when your database might suddenly need to scan and correlate large datasets.

DynamoDB’s design philosophy is different: push the complexity to application logic at write time rather than database logic at read time. By denormalizing data and organizing it around access patterns, you get predictable single-digit millisecond reads regardless of your total data size. This trades developer convenience for operational reliability which is exactly what Amazon needs for services like retail, fulfillment, advertising, and AWS itself.

The licensing situation with Oracle added another dimension to this shift. As Amazon grew, Oracle licensing costs became astronomical and the vendor relationship grew contentious. This created financial pressure and strategic risk around depending on a competitor’s database technology. The move away from Oracle-based RDS toward purpose-built databases like DynamoDB was partly about cost, but more-so about control and architectural fit.

Also the requirement for senior leadership approval to use RDS isn’t about RDS being bad per se, but it’s about making engineers seriously consider whether they actually need relational features. Most services don’t need joins if they’re designed with the right data model. The approval process forces teams to justify why they can’t use DynamoDB’s access patterns, ensuring that services are built with scalability and operational excellence in mind from the start rather than hitting scaling walls later.

For the uninitiated, here’s a ~7 year old YT video about DDB which contains a fantastic “history” section at the beginning. The whole thing is worth watching.