The short answer
The choice comes down to who holds the pager for the engine. With a managed database, a provider runs the server, the operating system and the replication. You own the schema, the queries and the indexes. With a self-hosted database, you own all of it: the machine, the engine version, the backup job and the failover script.
Neither option is simply cheap. Managed trades money for time and cuts the number of things that can wake you up. Self-hosted trades your team's hours for control over versions, extensions, kernel settings and network placement.
For most small and mid-sized teams, managed is the right default. Host it yourself when you have a concrete reason: an extension the provider will not enable, a version you must pin, a network path the provider cannot reach, or a workload so steady that per hour pricing stops making sense.
| Aspect | Managed database | Self-hosted database |
|---|---|---|
| Who patches the engine | Provider applies minor versions in your maintenance window. You choose when major upgrades run, within the versions offered. | Your team schedules and tests OS and engine patches, including security fixes, and applies them itself. |
| Backups and point in time recovery | Snapshots and log archiving run automatically. A restore usually creates a new instance with a new endpoint. | You build the backup job, ship logs to object storage, set retention and test restores on your own schedule. |
| Failover | A standby in another zone is promoted by the provider, and the app reconnects through the same endpoint. | You run Patroni, repmgr or similar, with fencing, health checks and a promotion path you have rehearsed. |
| Extensions and settings | Limited to an allow list. Some parameters are exposed as settings, but the config file and superuser are withheld. | Full control of extensions, shared preload libraries, kernel parameters, filesystem and engine build. |
| Scaling reads | Add a read replica in the console in minutes, then watch replication lag from the provider's metrics. | Provision a server, set up streaming replication, add it to the pooler and route read traffic yourself. |
| Access and permissions | The provider controls the host and admin roles. You grant database roles through SQL or a cloud IAM policy. | You control SSH, OS users, database roles, firewall rules and audit logging end to end. |
| Cost shape | Hourly charges for compute, storage, backups, IO and replicas. Retention, replicas and data transfer add up quietly. | Infrastructure invoices plus engineer hours for patching, upgrades, monitoring, restore drills and incidents. |
How a managed database works
You create an instance from a console, a CLI or a Terraform resource. You pick the engine and version, the size, the region, the replica count and the backup retention. The provider then does the parts that are easy to get wrong: installs the engine, applies minor patches in a maintenance window you set, fails over to a standby when the primary dies, and ships backups and write ahead logs so you can restore to a point in time.
What you get back is an endpoint, credentials and a database. Everything above that line is yours: migrations, index design, query plans, connection counts, role grants and data retention. Most managed engines withhold the real superuser, so loading an untrusted extension or editing the config file directly is not on the table.
Sharp edges show up in predictable places. Connection limits scale with instance size, so put a pooler in front, either the provider's or PgBouncer. Long running transactions and idle-in-transaction sessions block maintenance and can stall an upgrade. Read replicas lag, so code that writes and then reads from a replica will show stale rows.
Run a restore once before you need it. On most providers it creates a new instance with a new endpoint, and you repoint the app through a connection string or a DNS record.
How a self-hosted database works
You install the engine on a VM, on bare metal, or through an operator on Kubernetes. Then you build what a provider would have handed you. A backup job plus log archiving to object storage for point in time recovery. Replication with Patroni or repmgr so a standby can take over. Health checks and a failover you have actually triggered in a test. Exporters, a dashboard and alert rules for disk, replication lag, connections and slow queries.
The payoff is control. You choose the engine build, the extensions, the shared preload libraries, the kernel parameters, the filesystem and the timing of a major upgrade. You can keep the database inside a network segment with no route to the internet.
The cost is that every failure mode is yours. A disk that fills at night stops writes. A backup job that reports success but writes truncated files is worse than no backup. A failover with bad fencing can leave two primaries taking writes. Self-hosting works best when someone on the team has run a database in production and has hours to keep doing it.
When to choose a managed database
Pick managed when nobody on the team wants to be a database administrator. You get a cross zone standby, automated backups and point in time recovery in an afternoon, not a quarter.
Pick it when load is spiky or hard to predict. Resizing, adding a read replica and growing storage are console actions, and you can undo most of them the same day.
Pick it when the database is not your product. Security reviews also go faster, because providers publish audit reports and answer questionnaires you would otherwise fill from scratch. Before you commit, check the extension list against what your app needs, confirm the connection limit and pooler options, and read how major version upgrades work.
When to choose a self-hosted database
Host it yourself when you need something the provider will not give: a patched engine build, an extension off the allow list, superuser access for a replication setup, a custom collation or a specific shared library.
Host it yourself when data placement or network rules demand it. Some customers and regulators require the database in a named country, or on a private subnet with no provider control plane access.
Host it yourself when utilization is steady and high, or the dataset is very large. Per hour pricing and storage charges start to dominate, and a reserved machine plus your own disks can win, if you count engineer time honestly.
Host it yourself when you have someone who has done it before and upgrade timing matters to the product. Pinning a version, testing the upgrade on a copy and patching on your own schedule is a real benefit.
Costs and effort to consider
Managed pricing bundles compute, storage, backups, IO and replicas into one invoice. The lines that grow quietly are backup retention beyond a week, extra read replicas, cross region copies, IO on write heavy workloads, data transfer out, and instances left running after a project ends.
Self-hosted invoices look smaller. The rest shows up as engineer hours: patching, upgrade projects, backup checks, restore drills, monitoring upkeep and the night a disk filled. Price those hours before you call it cheaper.
Both paths need the same things around the database: versioned migrations, a pooler, a habit of reading query plans, an alert on replication lag and disk, and a restore you have tested. Set them up before the first incident.
Some teams split the work. Managed for the primary transactional database, self-hosted for a small analytics or cache database where tuning matters. Others start managed and move later, once the workload is known. If your team still deploys by hand, the database is not the first thing to fix. Cloudverg's Delivery platform setup package, $14,500/month, puts pipelines, environments, secrets, monitoring and rollback in place over four weeks. A managed database from a cloud provider is another option, and so is hiring an operations engineer.
Frequently asked questions
Is a managed database more expensive than self-hosting?
On the invoice, usually yes. The comparison only makes sense when you price in the engineer hours for patching, backup checks, upgrade projects and incident response. For a small team without a database specialist, managed is often the cheaper path once those hours are counted.
Can I move from a managed database to self-hosted later?
Yes. Seed a self-hosted server with a logical dump or native replication, run both for a while, then cut over during a short write freeze. Most of the work is testing the cutover and writing down the rollback, not copying the data.
Do managed databases handle backups for me?
The provider runs the backup jobs and keeps the snapshots. You still own the restore decision: which point in time, which instance, and how the application gets repointed to it. Test a restore on a schedule so the steps are familiar.