I've been running databases on RDS for 4 years now, and here's the reality: RDS is what you use when you want to sleep at night instead of getting paged about database issues.
The Problem RDS Actually Solves
Look, running your own database on EC2 seems cheaper until your primary goes down at 2am on a Saturday and you realize you never properly tested your failover scripts. Been there, done that, got the therapy bills.
RDS handles the shit you forget about:
- OS patches that break everything: They test compatibility first
- Backups that actually work: Unlike my "clever" cron job that failed silently for 3 months
- Failover that doesn't suck: Multi-AZ actually works (usually under 60 seconds)
- Storage that doesn't fill up: Auto-scaling saved my ass more times than I'll admit
- Security patches: Applied during maintenance windows instead of emergency 3am deploys
The catch? It costs about 40% more than doing it yourself. But unless you enjoy explaining to your CTO why the database is down, it's worth it.
What Databases You Can Actually Run
RDS supports six engines, but here's what I've learned using them in production:
Aurora - AWS's custom MySQL/PostgreSQL. Expensive as hell but fast. The storage auto-scales so you won't wake up to a full disk, and failover actually works. Don't use Aurora Serverless v1 - it's garbage. v2 is decent but still has cold start issues.
PostgreSQL - The good choice. Handles JSON like a champ, has sane defaults, and version 16 finally fixed the parallel query issues. Avoid versions 12-13 if you can - they have memory leak problems under heavy load.
MySQL - Works fine for most stuff. Don't upgrade to 8.4 yet - it breaks half the ORMs. Stick with 8.0 for now. The binary logging changes in 8.4 will fuck up your replication.
MariaDB - MySQL but better. Columnstore is actually useful for analytics. If you're stuck on MySQL, consider this instead.
Oracle - Expensive but bulletproof. Licensing costs more than your car payment. Only use if you're already committed to the Oracle ecosystem or have compliance requirements.
SQL Server - Decent if you're in Microsoft-land. Express edition is fine for small apps, but you'll hit the 10GB limit faster than you think.
How RDS Actually Works (The Shit They Don't Tell You)
There are three ways to run RDS, and each has gotchas:
Single-AZ - One database in one data center. Cheap but risky. When AWS has an outage (and they will), you're fucked. Good for dev/test, terrible for anything that matters. I learned this the hard way when us-east-1 went down and took our staging environment with it.
Multi-AZ - Two databases, one active, one standby. Costs double but actually works. Failover usually takes 60-120 seconds, not the "seconds" AWS claims. The standby is invisible - you can't read from it, which is annoying. But when your primary goes down, you'll be glad it exists.
Multi-AZ DB Clusters - The new hotness with readable standbys. Faster failover (actually under 35 seconds) and you can read from the standbys. Costs even more but worth it for critical workloads. Only available for MySQL and PostgreSQL, Oracle users are still stuck with regular Multi-AZ.
Performance Reality Check
RDS performance depends on three things: instance size, storage type, and whether you configured it right:
Instance Classes - Start with r6i for anything serious. r7i is newer but costs 20% more for marginal gains. Don't use t3/t4g instances for production - they're burstable, which means unpredictable performance when you need it most. Learned this during Black Friday when our t3.large started throttling.
Storage Types - gp3 is the default choice. It's fast enough and cheaper than the old gp2. Don't use io2 unless you're actually hitting IOPS limits - it's expensive and most apps don't need 256k IOPS. Magnetic storage is deprecated for good reason - it's slow as shit.
Read Replicas - Up to 15 replicas sounds great until you realize replication lag can be 200ms+ during heavy writes. Cross-region replicas are worse - expect 500ms+ lag. Don't route critical reads to replicas unless you can handle stale data. PostgreSQL logical replication is better but requires more setup.
Security (And the Gotchas You'll Hit)
RDS security is pretty good out of the box, but there are things that'll bite you:
Network Setup - Always put RDS in private subnets. If your database is internet-accessible, you fucked up. Security groups are your friend - default deny everything, then open specific ports. Don't use 0.0.0.0/0 unless you enjoy explaining data breaches to your boss.
Encryption - Enable it from day one. You can't encrypt an existing database without a migration. KMS keys cost pennies, but forgetting encryption will cost you compliance headaches later. SSL/TLS is on by default but your app still needs to use it.
Access Control - IAM database authentication sounds cool but it's a pain to set up. Most people stick with database passwords stored in Secrets Manager. Auto-rotation works but test it first - I've seen it break apps that cache connections.
Compliance - RDS covers SOC, PCI, HIPAA, etc. but YOU still need to configure it right. AWS gives you the tools, not the implementation. Passed a SOC audit last year - the auditors care more about your processes than AWS's certifications.
Pro tip: auditors will ask for your encryption key rotation logs. Set up CloudTrail for KMS events before your audit, not during.
2025 Reality Check - Performance Insights is getting killed on November 30, 2025. AWS is pushing everyone to CloudWatch Database Insights instead. Start planning the migration now because the replacement costs more.
Bottom line: RDS handles the infrastructure security so you can focus on screwing up the application security instead.
