Managed vs. Self-Managed Databases in the Cloud

The database is where "who operates this" stops being abstract

For most application tiers, the run-it-yourself-or-rent-it question is easy: web and worker processes are stateless, disposable, and cheap to rebuild. The database is the opposite. It holds the state everything else depends on, it is the hardest thing to move, and it is where a bad night turns into data loss rather than a restart. So the decision to run a managed service like Amazon RDS, Aurora, Azure SQL, or Cloud SQL versus standing up your own engine on virtual machines is the one placement choice worth slowing down for.

The trade is not managed-is-better or self-hosted-is-cheaper. It is a specific exchange: you hand off a large block of undifferentiated operational labor in return for less control, a pricing premium, and a degree of lock-in. Whether it pays depends on the workload, the team, and the licensing math. Here is how we weigh it for clients running production data.

What a managed database service actually operates for you

The value of a managed service is the operational work that disappears from your plate. That work is real, and underestimating it is the most common mistake in these comparisons.

• Patching and minor-version upgrades. The provider applies engine security patches and minor releases during a maintenance window you define. On a self-managed fleet, you own the entire cycle: track CVEs, test the patch, and apply it without dropping connections mid-transaction.
• Automated backups and point-in-time recovery. Managed services take continuous backups and let you restore to a chosen second within the retention window, usually with a few clicks. You still have to test restores, but you are not writing and babysitting the backup jobs.
• High availability and failover. A managed multi-availability-zone deployment keeps a synchronous standby and promotes it automatically, typically in one to two minutes, when the primary fails. Building equivalent automatic failover by hand — replication, health checks, a fencing mechanism to prevent split-brain, and a floating endpoint — is a genuine engineering project.
• Read scaling and storage growth. Adding read replicas is an API call, and storage on many services auto-grows so you do not get paged at 2 a.m. because a volume filled.
• Monitoring and the boring plumbing. Baseline metrics, slow-query insight, encryption at rest, and automated failover of the connection endpoint arrive configured rather than assembled.

Figure: a managed service assembles primary, standby, replica, and backup tiers by default — self-managing means building and operating every slab yourself.

None of this is impossible to run yourself. The point is that it is undifferentiated — it does not make your product better, and every hour spent on it is an hour not spent on the workload. For teams without a dedicated database engineer, the managed premium often costs less than the labor and risk it removes.

What you give up: control, tuning ceilings, and cost

The other side of the trade is equally concrete. A managed service is a guardrailed environment, and the guardrails are where teams with real performance needs hit friction.

• Superuser and OS access. You do not get root on the host, and often not true superuser inside the engine. That blocks certain extensions, custom background workers, kernel and filesystem tuning, and any diagnostic that needs to touch the operating system.
• Configuration ceilings. You tune the parameters the provider exposes, not the ones it does not. Memory settings, checkpoint behavior, and connection limits are adjustable; some low-level knobs simply are not reachable.
• Extension and version constraints. You run the engine versions and the approved extension list the provider supports. A niche extension your application depends on may not be available at all.
• Cost at scale. The managed premium runs roughly 20 to 40 percent above the raw compute and storage for comparable capacity, and it compounds with every replica and backup-storage gigabyte. For a large, steady, round-the-clock database, it can exceed the fully loaded cost of running the same engine on your own high-performance servers.

Self-managing on VMs gives all of that back: full OS and engine access, any extension or fork you want, kernel-level I/O and memory tuning, and hardware you size deliberately rather than picking from a menu. For a database that lives at the edge of what an engine can do — heavy write throughput, latency-sensitive queries, unusual extensions — that control is not a luxury, it is the reason the workload performs. The cost is that you now own every task in the previous section, plus the pager that comes with them.

Licensing quietly changes the answer

For open-source engines like PostgreSQL and MySQL, licensing is a non-issue and the decision is purely operations versus control. For commercial engines, licensing frequently dominates the math.

• Bring-your-own versus license-included. Managed services for SQL Server and Oracle often bundle the license into the hourly rate, which is convenient but builds a recurring cost into every running hour and every replica.
• Core-based licensing on self-managed hosts. Run the same commercial engine on your own VMs and you license by core, which means denser or higher-frequency hosts can cut license count — sometimes the single largest line item, dwarfing the hardware.
• Edition traps. Some high-availability and encryption features are gated behind an enterprise edition. Confirm that the tier you are licensed for actually includes the capabilities your architecture assumes before you commit.

The practical rule: for commercial databases, model the license cost on both sides explicitly. It moves the break-even more often than compute does, and it is the number most comparisons leave out.

Lock-in and migration: how hard is the exit

Every managed service creates some gravity. The question is how much, and whether you can afford it later.

Lower lock-in. A managed PostgreSQL or MySQL that runs a standard engine version is close to portable. Your schema, queries, and drivers are the same whether the engine runs on RDS, on Azure, or on a VM you own. Migration is a logical dump-and-load or a replication cutover — real work, but bounded.

Higher lock-in. Provider-specific engines and serverless data platforms — Aurora's storage layer, DynamoDB, Spanner, Cosmos DB — trade portability for capability. They can be excellent, but their APIs, data models, and operational behavior have no drop-in equivalent elsewhere. Leaving means re-architecting, not just re-hosting.

Protect the exit deliberately:

1. Prefer standard engine versions when portability matters more than the last increment of a proprietary feature.
2. Keep an independent backup in a portable logical format, held outside the provider account, so you are never trapped by a platform-native-only copy.
3. Isolate provider-specific features behind a data-access layer instead of letting them leak across the whole codebase.
4. Rehearse the migration path before you need it. An exit you have never tested is a plan on paper.

Even a fully managed database still runs inside networking, identity, and backup boundaries you own — the disciplined server infrastructure management around it does not go away just because the engine host does.

When each model makes sense

Put the trade-offs together and the placement rules are fairly clean.

Reach for a managed service when:

• You have no dedicated database engineer, and undifferentiated operations are a distraction from the product.
• The workload uses a standard open-source engine with common extensions.
• Availability and recovery targets are strict and you would rather buy proven failover than build it.
• Demand is variable or growing, and painless read-replica and storage scaling are worth the premium.

Self-manage on VMs when:

• You need OS-level access, a niche extension, or tuning the provider does not expose.
• The database is large, steady, and round-the-clock, where the managed premium over years exceeds the loaded cost of owning the capacity.
• Commercial licensing on dense, self-managed hosts materially beats the license-included managed rate.
• You have the database engineering depth to run patching, HA, and backups to a standard you can defend at 2 a.m.

Most estates land on a mix: managed services for the many ordinary databases where operations are pure overhead, and self-managed hosts for the handful of performance- or license-sensitive systems that justify the effort.

Get the placement decision right the first time

Managed versus self-managed is not a philosophy, it is a per-database calculation: the operational labor you shed, the control and performance ceiling you accept, the licensing on both sides, and how hard the exit is if you change your mind. Get it right and you stop paying a premium for control you never use — or stop hand-rolling failover you could have bought. intSignal's cloud infrastructure team models this for each database and operates the result, managed or self-hosted, to the same standard. Talk to us to place your data tier deliberately instead of by default.