Managed vs Self-Hosted PostgreSQL: Total Cost of Ownership

Compare a managed PostgreSQL plan against renting the equivalent VPS and the managed option looks expensive: you can rent the same vCPUs and RAM for a fraction of the price, install Postgres in ten minutes, and pocket the difference. The comparison is real — but it is a comparison of server bills, not of what a production database actually costs to run. This article itemises the difference, because the right answer genuinely differs by team.

For transparency: we sell managed PostgreSQL hosting, so we have an obvious interest here. We have tried to keep the analysis honest anyway — including the section on when you should not pay for managed.

What does “managed” PostgreSQL actually include?

A managed PostgreSQL service runs the database engine for you: provisioning, automated backups with point-in-time recovery, minor version patching, failover or easy restore, monitoring with alerts, and support from people who operate Postgres all day. You still own schema design, query performance and application-level decisions — managed is not a DBA replacement for your data model, it is a replacement for the operational layer beneath it.

What does self-hosting PostgreSQL really involve?

Installing PostgreSQL is genuinely easy. Operating it to a production standard means owning all of the following, indefinitely:

• Backups that restore. Nightly pg_dump is the floor, not the standard. Production-grade means continuous WAL archiving for point-in-time recovery (with tooling such as pgBackRest or WAL-G), offsite copies, and — the step almost everyone skips — regularly testing a restore. An untested backup is a hope, not a backup.
• High availability. A single node means downtime whenever the host reboots or fails. Streaming replication plus safe failover (Patroni or repmgr, plus connection routing) is a proper engineering project with sharp edges — split-brain scenarios are how you lose data, not just uptime.
• Patching and upgrades. Minor releases arrive roughly quarterly and sometimes carry security fixes; each major version is supported for about five years, so major upgrades are a recurring, planned event — pg_upgrade or logical replication, rehearsed on a copy first.
• Monitoring and alerting. Disk space, replication lag, connection saturation, autovacuum health, transaction ID wraparound. These fail quietly and then all at once; you need dashboards and alerts before the incident, not after.
• Tuning and security. Sensible shared_buffers, work_mem and autovacuum settings for your workload; TLS, authentication, network restrictions and an upgrade story for the OS underneath.

None of these tasks is individually hard for a competent engineer. The cost is that they are permanent: an on-call responsibility that never ships and never finishes.

How do the costs actually compare?

The honest comparison prices the engineering time. UK contractor and salary rates put a capable ops engineer's time at roughly £50–£100+ per hour once employment costs are included; even a modest two to four hours a month of routine care — before any incidents — prices self-hosting's “free” operational layer at more than most managed plans. The table shows where each cost lives rather than pretending to universal numbers:

When does managed PostgreSQL win?

• Small teams without a dedicated ops function. If your developers would be the DBAs, every hour they spend on WAL archiving is an hour not spent on the product — and databases are uniquely unforgiving of part-time attention, because the failure mode is data loss rather than downtime.
• Anything where restore-confidence matters more than margin. Client work, ecommerce, SaaS with real customers: the first unrecoverable incident costs more than years of managed fees.
• Apps where the database is critical but boring. A Laravel or Next.js app with a straightforward relational schema gains nothing from bespoke database operations.

When does self-hosting win?

Genuinely, and not rarely:

• You already have the ops capability. A team that runs its own infrastructure with real on-call, monitoring and backup discipline adds Postgres at low marginal cost — the “engineering hours” line is already paid for.
• Scale has made the managed premium bigger than a salary. Managed pricing scales with instance size; at large fleet or very-large-instance scale, the premium can exceed the cost of the DBA capacity it replaces. This is why big companies insource — and why it is the wrong reason for a three-person startup to.
• You need what managed platforms can't offer. Unsupported extensions, exotic replication topologies, specific kernel or filesystem tuning, or strict data-residency setups where you must control the exact machine.
• Cost floors matter more than time. Hobby projects and internal tools with tolerable-loss data are fine on a single VPS with nightly dumps — matching the operational standard to the stakes is good engineering, not negligence.

Is there a middle ground?

Yes, and it suits more teams than the binary framing suggests. You can self-host the database engine on a VPS while outsourcing the scariest component: run Postgres yourself but point pgBackRest at object storage with a tested restore runbook, or use a managed server product where the provider patches the OS while you run the database. Conversely, some teams start managed and repatriate later once scale justifies it — a sensible sequence, provided you avoid provider-specific extensions and keep your schema portable, so the exit remains a data migration rather than a rewrite. The architecture decision and the operations decision are separable; treat them that way.

What questions decide it for your team?

1. Who restores the database at 3 a.m., and have they rehearsed it? If there is no confident answer, you want managed.
2. What is an hour of your engineers' time worth against the managed premium? Multiply honestly, including incidents.
3. What does an hour of downtime — or a day of lost data — cost the business? This sets how much HA and PITR you need, whoever provides it.
4. Will you actually do the unglamorous work? Restore tests, minor upgrades, monitoring reviews. The realistic answer, not the aspirational one.

The bottom line

The server bill is the smallest part of what PostgreSQL costs to run properly. Managed services charge a visible premium to absorb an invisible workload; self-hosting hides that workload in engineering hours that are only cheap if they were already budgeted. Small teams and product-focused companies are usually better off managed; teams with real ops capacity, unusual requirements, or serious scale are usually better off self-hosting. Price the hours, not just the hardware, and the decision mostly makes itself.