Managed vs self-hosted databases: benefits, cost, lock-in

The main benefit of a managed database over self-hosting is failover you don't have to build: a cluster that keeps replicas in sync and switches to one when the primary goes down. The schema, the queries, the indexes and the test restore are still yours. A managed service runs the cluster, not your data model.

On American Cloud, that cluster costs $56.38 a month more than three VMs of the same total size. That's under an hour of a database administrator's time. A single managed node is $16.09 more than the closest VM and buys a fast deploy and a backup scheduler, not failover.

What's the difference between a managed database and doing it yourself?

Here's who does each job with our managed PostgreSQL or MySQL, and with the same engine on a VM you set up yourself:

What building failover yourself looks like

On VMs, "automatic failover" is a small system of its own. The common open-source way to build it for PostgreSQL is Patroni, which describes itself as "a Python template for building PostgreSQL high availability (HA) clusters." A typical setup has four parts:

1. Three servers running PostgreSQL, one primary and two replicas kept up to date by streaming replication.
2. A distributed configuration store the nodes use to agree on which one is primary. Patroni supports etcd, Consul, ZooKeeper and Kubernetes, so that's one more clustered service to run.
3. Patroni on every node, which watches the primary and promotes a replica when it stops answering.
4. Something that sends your app to whichever node is primary right now, such as HAProxy in front of the cluster.

MySQL has its own version of the same stack. MySQL InnoDB Cluster is "a group of at least three MySQL server instances" running Group Replication, set up through MySQL Shell. If the primary fails, a secondary is promoted, and MySQL Router sends your app to the new primary. Fewer moving parts than Patroni, but it's still three servers, a router and a replication mode you have to understand when it misbehaves.

Each part has its own config, its own upgrades and its own way of failing. And none of it is proven until you've stopped the primary on purpose and watched a replica take over without your app noticing. That drill, repeated after every change to the setup, is most of the real cost of self-hosted high availability.

What a managed database costs compared with running it yourself

Our list prices, Standard tier, monthly, as of October 26, 2026:

VMs are $10 per vCPU, $5 per GB of memory and $1 per 16 GB of disk a month, and the network a new VM creates for itself is free. The three small VMs have 2 GB more memory between them, and the medium ones 7 GB more, because VM memory comes in fixed sizes (4, 8, 16 GB and up). None of those VMs has failover set up. The gap doesn't grow with the cluster: it's smaller at the medium size than at the small one.

The U.S. Bureau of Labor Statistics puts the median pay for database administrators and architects at $60.94 an hour (2025). At that rate, $56.38 is about 55 minutes of their time a month, and $16.09 about 16 minutes. If building and keeping failover working takes your team less than an hour a month, self-host. Count the first build and the first failover drill, not just the quiet months.

The one-node plan is a fair deal for staging. Every plan and engine is on the managed databases page.

Benefits of a managed database service

When the primary dies at 3 a.m., a replica takes over on its own, and nobody on your team had to build or test the failover. Beyond that, you get a staging database whenever a branch needs one, and backups on a schedule with a retention policy once you've set a backup destination. When the data grows, you add storage from the database's Settings tab, and the increase applies right away with no downtime. On a VM, growing a disk under a running database is a job you plan for.

When self-hosting is the better call

• Someone on your team already runs Postgres replication and has done a failover drill. You'd be paying for work you already know how to do.
• You need the server itself: the filesystem, the config files, an extension you compile.
• The database is throwaway, like a dev copy you'd rebuild from a dump anyway.

Which is more reliable, self-hosted or managed?

Neither, by itself. Reliability is a replica that can take over plus a backup you've actually restored. The three-node plan gives you the first. The second is your job on both sides: restore last night's backup into a test database once. A backup nobody has restored is a hope.

The simplest restore test works the same on a managed database and on your own VM. Take a custom-format dump, create an empty database somewhere else, and restore into it. These are the commands from the pg_restore docs (PostgreSQL 18), with mydb as your database:

pg_dump -Fc mydb > db.dump
createdb -T template0 newdb
pg_restore -d newdb db.dump

Then run a few of your app's real queries against newdb, and compare row counts on your biggest tables with production. How long the restore takes is how long a full recovery from a dump takes, so write that number down where the person on call can find it.

Open-source vs proprietary managed databases: the lock-in tradeoff

The engine decides how hard leaving is. A managed PostgreSQL or MySQL moves with pg_dump or mysqldump, and your app reaches the new host with the same driver and a new connection string. A database with its own API, sold by one provider, means rewriting your data layer to leave.

Open source alone doesn't protect you, though. Aiven ended its managed Apache Cassandra service, and since January 7, 2026, those services are no longer available and the data they hosted is inaccessible. Cassandra is open source. What saves you in that case is a recent copy of your data somewhere else.

So an open exit takes three things: an open-source engine, a dump you've restored on another host at least once, and no bill for taking your data out. American Cloud doesn't charge egress fees, so a full export costs nothing in transfer.

Pick a managed service you can leave without a fee or a rewrite. More on that in our vendor lock-in guide.

Should startups use a managed database?

Yes, for anything where downtime costs you customers. If you have to ask whether your team runs its own failover, it doesn't. Put production on the three-node plan from day one and staging on a development plan, and move up a tier when the database outgrows its plan. A team that already runs its own Postgres failover can start on a VM instead: our Heroku alternatives guide prices that setup for a typical Rails app.

Starting on a VM doesn't lock you out of the managed plan later. The move is the same dump and restore as the drill above, then a new connection string in your app. Run the drill first, and the move is the second time you've done it.