The price difference between a managed database and the same database on your own server looks indefensible until the first time you need point-in-time recovery at 2am. Then it looks cheap. Both reactions are correct; they are just measuring different things.
What a managed service actually provides
- Automated backups with point-in-time recovery. Not a snapshot — a restore to a specific moment inside a retention window. This is the feature most people underestimate and most need.
- Failover. A standby that is promoted automatically when the primary fails, generally in under a minute.
- Patching during a maintenance window you choose, without you tracking security advisories.
- Read replicas as a configuration change rather than a project.
- Connection handling, metrics and slow query visibility as standard.
Replicating that on your own server is entirely possible and is measured in days of setup plus ongoing attention, not hours.
What you give up
- Superuser. Extensions are limited to the supported list, and some configuration parameters are fixed.
- Filesystem access. Bulk load and restore paths that assume local files need reworking.
- Version timing. New major versions arrive when the provider supports them.
- Cost predictability at scale, because storage, I/O and backups are often metered separately.
When self-hosting is right
- The workload needs an extension or a configuration the managed service does not permit.
- The database is small, non-critical, and an hour of downtime is genuinely acceptable.
- Cost dominates and somebody on the team is already competent at database operations — that competence is the actual prerequisite, not the willingness.
- Data residency or regulatory requirements the managed offering does not meet.
“We can set it up ourselves” is true and is not the question. The question is whether somebody will still be maintaining it, testing restores and watching replication lag in eight months.
If you do self-host, do these five things
- Automated logical dumps and continuous archiving, both written off the machine. See snapshots vs backups.
- A restore you have actually performed and timed.
- A standby, or at least a documented rebuild procedure with a known duration.
- Monitoring on replication lag, connection count and disk space — disk full is the classic database outage.
- The database on the private network only, never exposed publicly. See firewall rules.
The middle path
Self-host in development and staging where the operational burden does not matter, and use the managed service in production where it does. The application talks to the same protocol either way, and the team gets the benefit of both.
Where to go next
- How much RAM a cloud server needs
- Block, object and file storage
- Estimating cloud costs before you build
Questions
Frequently asked
Is a managed database worth the price difference?
It depends what an hour of downtime and an unrecoverable dataset cost you. The point-in-time recovery and automatic failover are the features being paid for, not the database itself.
Can I run Postgres on a normal cloud server?
Yes, and many do. The requirement is not the installation but the ongoing work: backups that are tested, monitoring on replication and disk, and a documented recovery procedure.
What do I lose with a managed database?
Superuser access, arbitrary extensions, some configuration parameters and filesystem-level operations. For most applications none of these matter; for some they are decisive.