Self-hosting Postgres in 2026: what actually matters

A managed PostgreSQL instance on AWS RDS costs $50-200/month for a small production workload. The same workload on a $7/month Hetzner VPS runs faster (dedicated vCPU, local NVMe) and costs 90% less.

The catch: you have to manage it yourself. Backups, monitoring, failover, upgrades, security patches. That is real work. But in 2026, the tooling has caught up.

What you actually need

Automated backups. pg_dump on a cron job is the minimum. For production, WAL archiving with pgBackRest gives you point-in-time recovery. nSelf configures this automatically: daily full backups, continuous WAL archiving, 30-day retention.

Monitoring. You need to know when the database is slow, full, or down. nSelf ships with Prometheus + Grafana + postgres_exporter. Out of the box, you get dashboards for connection count, query latency (p50/p95/p99), cache hit ratio, disk usage, and replication lag.

Connection pooling. PostgreSQL creates a new process for every connection. At 100+ connections, this gets expensive. PgBouncer sits in front and multiplexes connections. nSelf includes it in the default stack.

Security. TLS for all connections (nSelf generates certificates via Let's Encrypt). No public port exposure (Postgres binds to 127.0.0.1, accessed only through the internal Docker network or via Hasura). Automatic password rotation available via the nself secrets rotate command.

Upgrades. Major version upgrades (e.g., Postgres 16 to 17) require pg_upgrade or a dump-and-restore. nSelf handles this with nself db upgrade, which takes a snapshot, runs the upgrade, verifies data integrity, and rolls back automatically if anything fails.

What you do not need

Multi-region replication. Unless you are serving users on multiple continents with sub-50ms latency requirements, a single server in your target region is fine. For most applications, the network round trip between your app and database is under 1ms on the same machine.

Managed failover. If your VPS goes down, your entire stack is down anyway (app server, reverse proxy, everything). A managed database failover does not help when the compute layer is a single machine. For real HA, you need multiple servers, and at that point you are building a cluster, not choosing a database provider.

Read replicas. For applications under 10,000 requests per second, a single PostgreSQL instance with proper indexing and connection pooling handles the load without breaking a sweat. Premature scaling adds complexity without benefit.

The nSelf approach

nself init myapp
nself build
nself start

After those three commands, you have PostgreSQL running with:

• Automated daily backups (WAL archiving + pg_dump)
• Prometheus + Grafana monitoring
• PgBouncer connection pooling
• TLS on all connections
• Hasura GraphQL API in front (no raw SQL exposure)
• Automatic health checks every 30 seconds

Total cost: your VPS ($4-20/month depending on size). No per-query fees, no per-connection fees, no storage surcharges.

When to use managed

Managed databases make sense when: you have a dedicated ops team that costs more than the managed service, you need contractual SLAs for uptime, you need multi-region active-active replication, or your compliance requirements mandate a SOC 2 certified database provider.

For everyone else, self-hosted PostgreSQL in 2026 is straightforward, cheap, and fast.