Managed PostgreSQL vs Self-Hosted:
The Real Trade-Offs
Self-hosting PostgreSQL looks cheap on a spreadsheet. One VM, one database, no managed service markup. But the spreadsheet is missing most of the cost. Properly operated self-hosted PostgreSQL requires sustained SRE attention that most teams underestimate — until something breaks at 2am and nobody knows the Patroni configuration well enough to fail over without data loss.
What Self-Hosting Actually Requires
A production-grade self-hosted PostgreSQL cluster is not a VM with Postgres installed. Done correctly, it requires: initial tuning of shared_buffers (typically 25% of RAM), work_mem (sized per connection and query type), max_connections (balanced against PgBouncer configuration), and checkpoint settings to avoid I/O spikes. It requires a monitoring stack covering pg_stat_activity for connection saturation, replication lag for standby health, and long-running query detection. It requires automated failover — either Patroni with etcd/Consul, or pg_auto_failover — with a tested runbook for the cases where automation doesn't trigger cleanly. It requires WAL archiving to object storage for point-in-time recovery, tested quarterly. And it requires OS-level patching that does not break the Postgres service — which is more nuanced than it sounds when you're running custom kernel parameters for huge pages.
Self-Hosted PostgreSQL: Operational Checklist
-
Initial tuning — shared_buffers, work_mem, max_connections, checkpoint_completion_target, effective_cache_size. Wrong values here cause subtle performance regressions that appear weeks later.
-
Monitoring stack — pg_stat_activity, replication lag tracking, bloat monitoring (dead tuples from VACUUM lag), slow query log with pg_stat_statements.
-
Failover automation — Patroni or pg_auto_failover, with DCS (etcd/Consul) quorum properly sized to avoid split-brain. Needs regular testing — an untested failover is not a failover.
-
Backup and PITR — WAL archiving to separate storage, tested restores, documented RPO. pgBackRest or Barman are standard choices. Backups that have never been restored are not backups.
-
OS maintenance — Kernel updates, security patches, huge pages configuration, and ulimit settings without disrupting the Postgres service lifecycle.
What Managed PostgreSQL Handles for You
A well-built managed PostgreSQL service eliminates the entire operational layer above. Automated failover triggers in under 60 seconds using pre-configured streaming replication with a tested promotion sequence. Hourly backups with point-in-time recovery are standard. PgBouncer connection pooling is built in, preventing the connection saturation that kills self-hosted instances under load spikes. Minor version patching applies automatically on your chosen maintenance window. The monitoring dashboard surfaces the metrics that matter without requiring you to build the collection and alerting infrastructure.
Managed PostgreSQL Gives You
- • Automated failover under 60 seconds
- • Hourly backups + point-in-time recovery
- • PgBouncer connection pooling built in
- • Automated minor version patching
- • Built-in monitoring dashboard
- • Streaming replication pre-configured
Self-Hosted Still Makes Sense For
- • Unusual extensions at scale (PostGIS, TimescaleDB)
- • Datasets over 10TB with custom partitioning strategies
- • Regulatory requirement to control encryption keys
- • Teams with dedicated DBA capacity already on staff
The Real Cost Comparison
Self-hosted PostgreSQL requires 0.3–0.5 FTE of SRE time to operate correctly — not to build new features, just to maintain the database cluster. At a mid-market SRE salary in Tashkent of approximately $3,000/month, that is $900–$1,500/month in loaded labour cost before you count the VM. A 4-core 16GB VM to run the database costs approximately $200/month. Total: $1,100–$1,700/month.
A managed 4-core 16GB PostgreSQL instance on Hyper App runs approximately $600–800/month — fully managed, with all of the above included. That is a lower absolute cost with less operational risk, not a trade-off. The self-hosted option only wins on cost if you already have SRE capacity that is underutilised — and if that's the case, you have a different problem.
"We spent nine months debugging intermittent replication lag on our self-hosted cluster. The root cause was a misconfigured checkpoint_segments value. With managed PostgreSQL, that entire class of problem disappears."
— Backend Lead, Central Asian SaaS Company
How to Decide
If your team has no dedicated DBA or SRE, managed is the right choice — the risk-adjusted cost is lower even before you account for the 2am incidents. If your data has specific partitioning or extension requirements that managed services don't support, self-hosted is legitimate. For the majority of production PostgreSQL workloads in the 10GB–2TB range, managed is the better engineering decision, not just the more convenient one.