Cloud Database Selection Guide: Managed Services vs Self-Hosted – How to Decide

Three years ago, a SaaS company CTO bought me a drink. He looked exhausted.

Their business was growing, but their database was struggling. They ran self-managed MySQL on EC2. Full backups ran every night. In the early days, that worked fine—nighttime was quiet. But now they had users worldwide. During backups, I/O spiked and query latency doubled. Worse, two weeks earlier, the master disk filled up. They caught it in time, but that morning the whole team scrambled to add capacity. Nothing else got done.

"I'm thinking about moving to RDS," he said. "But I'm worried about cost. And migration sounds painful."

This is the dilemma every technical leader faces: self-managed gives you control but keeps you up at night. Managed services cost more on paper but promise peace of mind. How do you actually decide?

Today, let's talk about cloud database selection. Not the usual "it depends" fluff, but a real framework: What's the difference between managed and self-hosted? When do you pick which? And how do you calculate the real cost?

01 First, What Does "Managed" Actually Manage?

Many people think RDS is just "MySQL installed in the cloud." It's much more.

Managed services (RDS, Aurora, Cloud SQL) handle all of this for you:

• Hardware maintenance: Disk fails? CPU dies? Cloud provider replaces it. You don't know it happened.

• Security patching: Critical database vulnerability? Provider applies patches (on your schedule).

• Backup and recovery: Automated full + incremental backups. Point-in-time recovery built in.

• High availability: Multi-AZ failover. You barely notice.

• Monitoring: Dozens of preconfigured metrics, integrated with cloud monitoring.

• Read replicas: Create them with one click. Scale reads instantly.

Self-managed? You do all of this yourself. Write backup scripts. Set up replication. Build failover. Monitor disk space. Apply patches. Every single task takes time.

So "managed" really means: spend money to buy time and peace of mind.

02 The Real Cost: Is Managed Really More Expensive?

Most people look at RDS pricing—20-30% more than equivalent EC2 instances—and conclude it's not worth it. But that's counting servers, not counting people.

Let's do a real comparison.

Assume a mid-sized workload: primary 8-core 32GB, two read replicas, 500GB data.

Self-Managed (MySQL on EC2):

• 3 EC2 instances (primary + 2 replicas): 3-year reserved instances, monthly ~$600 each = $1800

• Backup storage: 500GB x 3 copies = 1.5TB, monthly ~$90

• Operations labor: At least 0.5 FTE (backups, monitoring, failover, patching, troubleshooting). At $80K/year engineer, that's $40K/year = $3333/month

• Total monthly: $1800 + $90 + $3333 = $5223

Managed (RDS for MySQL):

• 3 instances (primary + 2 read replicas): same specs, monthly ~$750 each = $2250

• Backup storage: Free up to 100% of instance storage. Assume 500GB extra = $30

• Operations labor: 0.1 FTE (only application-level tuning, no infrastructure) = $667/month

• Total monthly: $2250 + $30 + $667 = $2947

That's 44% cheaper for managed in this scenario.

This doesn't even include the value of high availability, automated failover, and not getting paged at 3 AM.

Of course, at massive scale—hundreds of instances—the economics shift. Self-managed spreads labor costs across more instances. But for small to medium scale, managed is often cheaper.

Counter-intuitive truth: Managed isn't necessarily more expensive. Factor in labor, and it's frequently cheaper.

03 What About Performance?

Another common concern: "Isn't self-managed faster because I can tune everything?"

Not really.

• RDS runs on EC2, but networking and storage are optimized. I/O latency is usually better than self-managed.

• Aurora is cloud-native—storage and compute separated. Throughput crushes self-managed MySQL, especially for read-heavy workloads.

The catch: with managed services, some low-level parameters (like innodb_buffer_pool_size) are fixed. You can't tweak kernel settings. If you need extreme, custom tuning, self-managed gives you that flexibility.

But for 95% of workloads, managed performance is more than enough. The other 5% are hyperscale or niche use cases where you really need that last 5% of performance.

04 When Should You Self-Host?

Managed is great, but it's not for everyone.

Scenario 1: Massive scale, cost-sensitive. If you run thousands of instances, building your own database engineering team can be cheaper than paying the managed premium.

Scenario 2: Special versions or plugins. Need an old MySQL version RDS doesn't offer? Require a custom plugin? Self-managed gives you that control.

Scenario 3: Compliance or data sovereignty. Some regulations demand data on specific hardware, or through specific auditing processes that managed services can't guarantee.

Scenario 4: You already have a DBA team. If you've invested in deep database expertise, they probably prefer full control anyway.

05 Is Migration Hard?

Many teams delay the decision because "migration sounds painful."

It's actually easier than you think. Cloud providers have built tools for this.

• DMS (Database Migration Service): Migrates with minimal downtime. Source and target sync continuously; cut over when ready.

• Backup and restore: Take a full backup, restore to RDS, then configure incremental sync.

For MySQL to RDS: mysqldump to export, import to RDS, then DMS for ongoing sync. Pick a low-traffic window, cut over in an hour. Done.

That CTO I mentioned earlier? He spent a weekend migrating the core database to Aurora. Monday morning, no one noticed. He later told me: "I wish I'd done this three years ago."

06 A Decision Framework

Pick managed if:

• No dedicated DBA

• Business growing fast, want to focus on features

• Not chasing extreme performance

• Want HA/DR without building it

Consider self-hosted if:

• You have a DBA team

• Need special configs or plugins

• Massive scale makes it cheaper

• Compliance forces custom setup

The Bottom Line

That CTO friend? After moving to Aurora, his team stopped getting paged at night. The engineer who used to babysit backups now spends time optimizing slow queries. Application performance improved.

He told me something I haven't forgotten:

"I used to think self-managed was about saving money. Turns out, I was just spending money on tuition—tuition for lost sleep, tuition for emergency fixes, tuition for wasted time."

There's no universally right answer. Only the right answer for your scale, your team, your tolerance for operational pain.

Where is your database living today? And more importantly—who's paying the real cost?