Postgres

Self-hosting a database sounds terrifying. Cloud vendors spent a decade telling you it is. Here’s what actually happens when you run Postgres yourself.

TL;DR

• What it is: Open-source relational database with 35+ years of active development. The underlying engine inside AWS RDS, Supabase, Neon, Railway, and most other “managed database” services you’re already paying for [1].
• Who it’s for: Founders, developers, and small teams running side projects, internal tools, or production apps who want to stop paying $50–$300/month for a managed service wrapping the same software they could run for $5–$7/month [2][4].
• Cost savings: AWS RDS PostgreSQL runs $84/month for a small instance. AWS Aurora: ~$70/month. Supabase Pro: $25/month flat plus compute. Self-hosted on a $5–$7 VPS: under $10/month total [2][4].
• Key strength: It’s Postgres. Not a Postgres-compatible thing, not a fork, not a managed Postgres-as-a-service. The actual database. Free. Runs on any Linux server. Has every feature you’d get from a managed provider, because they’re running this same binary [1].
• Key weakness: You own the operations: backups, TLS, failover, upgrades, monitoring. A realistic estimate for ongoing maintenance is 4–8 hours per week for a single production instance — more during major version upgrades or incidents [5]. If that sounds like too much, that’s legitimate — this review will tell you when to stay managed.

---

What is Postgres

PostgreSQL is an advanced object-relational database management system that has been in continuous development since 1986. It supports full ACID transactions, foreign keys, subqueries, triggers, user-defined types and functions, and an extended subset of the SQL standard [postgresql.org]. It’s not a niche tool or an upstart — it’s the database running inside most of the “managed database” services you’ve heard of.

Here’s the part cloud vendors don’t emphasize: AWS RDS, Google Cloud SQL, Supabase, Neon, Railway, PlanetScale (Postgres variant), and others are, at their core, running the same open-source PostgreSQL binary with operational tooling wrapped around it [1]. As one engineer who migrated off RDS described it: “I took a pg_dump of my RDS instance, restored it to a self-hosted server with identical specs, and ran my application’s test suite. Performance was identical. In some cases, it was actually better.” [1]

The project sits at 20,310 GitHub stars on its mirror repository, though that number undercounts its true adoption — Postgres predates GitHub by two decades and most contribution happens through the mailing list, not pull requests. The most recent release as of this writing is version 18.3, alongside maintained versions 17.9, 16.13, 15.17, and 14.22 (released February 26, 2026) [postgresql.org].

The PostgreSQL License is a liberal open-source license similar to MIT or BSD. You can use it, modify it, embed it, and ship it in commercial products without restriction. No “Fair-code.” No BSL. No usage restrictions.

---

Why people choose to self-host it

The case for self-hosting Postgres breaks into two arguments: the cost argument and the control argument. Both are real.

The cost argument is simple math. One developer who audited every major database-as-a-service option in 2024 found: AWS RDS at $84/month, Aurora at $70/month, Supabase at $25/month for two databases (you need the Pro tier the moment you want a second project), Neon at $58/month for three databases, Firebase at $36/month. Against those numbers, a $7/month EC2 instance with self-hosted Postgres [2]. Over a year, that’s a real delta — $1,008 on AWS RDS versus $84 on a self-hosted VPS.

The cloud pricing pressure is accelerating. A db.r6g.xlarge instance on RDS (4 vCPUs, 32GB RAM) now costs $328/month before you add storage, backups, or multi-AZ deployment — the price for which you could rent a dedicated server with 32 cores and 256GB of RAM [1].

The control argument is less obvious but matters at scale. Managed services restrict which extensions you can install, cap configuration tuning (no root access means no kernel-level vm.overcommit_memory or transparent_hugepage adjustments), and prevent you from connecting custom shared libraries [5]. For most applications this doesn’t matter. For applications doing heavy analytics, custom data types, or unusual access patterns, it can be a genuine blocker.

One developer ran self-hosted Postgres for two years, serving thousands of users and tens of millions of queries daily. Their incident count: 30 minutes of stress during a manual migration. That’s it [1]. That experience — boring, stable, cheap — is the honest median outcome for self-hosted Postgres on a properly configured server.

The counter-argument from the managed-Postgres camp is equally honest: the “free” self-hosted stack quickly becomes the most expensive option when you factor in engineering time. A single full-time platform engineer costs more than a managed database subscription. Incident response, performance tuning, and version upgrades all land on your backlog [3]. The cost math only works if you’re not counting your own hours.

---

Features

PostgreSQL ships with a feature set that matches or exceeds most managed database services because, again, those managed services are running PostgreSQL [1].

Core database:

• Full ACID compliance with multi-version concurrency control (MVCC)
• Foreign keys, joins, views, triggers, stored procedures
• JSON and JSONB support — treat it as a document store when you need to
• Full-text search built in (no Elasticsearch required for basic search)
• Logical and streaming replication
• Partitioning for large tables
• Row-level security
• Extensions: pgvector for AI embeddings, PostGIS for geospatial data, pg_stat_statements for query analysis, timescaledb for time-series, and hundreds more via PGXN

Operational capabilities:

• pg_dump / pg_restore for logical backups
• WAL archiving for point-in-time recovery
• pg_upgrade for major version migrations
• Streaming replication for read replicas and failover
• High availability via Patroni, repmgr, or Stolon
• PgBouncer for connection pooling (critical at scale — Postgres spawns a process per connection)

What managed services add on top (and what you give up by self-hosting):

• Automated backups with retention policies
• Web dashboard for monitoring and restores
• One-click read replicas
• Automatic failover (with Patroni or repmgr you can replicate this, but you set it up)
• Connection pooling managed for you (PgBouncer configuration is non-trivial)

The extensions gap is real. Managed providers support curated lists. Self-hosted Postgres supports every extension on PGXN plus anything you compile yourself. If your workload needs pgvector for similarity search or PostGIS for geospatial queries, check your managed provider’s extension list before assuming they support it.

---

Pricing: SaaS vs self-hosted math

Managed PostgreSQL services (what you’re currently paying):

Provider	Monthly cost	Notes
AWS RDS PostgreSQL	$84/mo	Small instance, before storage/backups
AWS Aurora	~$70/mo	Cheaper than RDS, still significant
Supabase	$25/mo flat	Pro tier required for 2+ databases
Neon	~$58/mo	For 3 databases with reasonable compute
Firebase (Cloud SQL)	$36/mo	Per database
Railway	~$5/mo	Hobby tier, compute above $5 billed extra

Source: [2] for the full comparison.

Self-hosted on a VPS:

• Hetzner CX22: ~€4.49/month, 2 vCPU, 4GB RAM, 40GB SSD
• DigitalOcean Basic: $6/month, 1 vCPU, 1GB RAM
• Linode Nanode: $5/month, 1 vCPU, 1GB RAM, NVMe storage [4]
• Plus: $0.023/GB/month for S3 or Backblaze backups [4]

All-in self-hosted cost for a typical founder running 2–3 small databases:

• VPS: $7/month
• Backup storage (50GB): ~$1/month
• Total: ~$8/month

Versus Supabase Pro for the same 2–3 databases: $35–45/month [2].

Versus AWS RDS: $84–168/month for 2 instances.

Over 12 months, the delta between self-hosted and RDS for a small production workload is roughly $900–$1,900 per year. That pays for a lot of engineering time.

The honest asterisk: these numbers assume you already know how to set up a Linux VPS, run Docker, and configure a reverse proxy. If you’re starting from zero, add one afternoon of learning or a one-time deployment cost.

---

Deployment reality check

The DEV Community guide [4] frames Docker Compose as a 15-minute setup. That’s true for the happy path. Here’s the fuller picture.

Minimum viable self-hosted Postgres:

services:
  db:
    image: postgres:17
    container_name: postgres_db
    volumes:
      - pg_data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: your_strong_password
    ports:
      - "5432:5432"
volumes:
  pg_data:

That starts the database. Running it in production safely requires more:

Security hardening (non-negotiable):

• SSH key-only authentication, no root login [4]
• Firewall: only open port 5432 to your application servers, not the public internet
• Create application-specific database users with minimal permissions — never use the superuser account from your app [4]
• TLS for any connection crossing a network boundary [5]
• pg_hba.conf configured to reject connections from unexpected sources

Backups:

• Daily pg_dump compressed and shipped to S3 or Backblaze [4][5]
• WAL archiving if you need point-in-time recovery between daily snapshots
• Test your restores monthly — a backup you’ve never tested is not a backup [5]

Monitoring:

• Prometheus + Postgres exporter, Grafana dashboard for connections, replication lag, disk usage, long-running queries [4]
• Alerting before things break, not after

What can go sideways:

The operational burden is real. A realistic estimate for a production instance: 4–8 hours per week ongoing, more during major version upgrades [5]. Major version migrations (e.g., Postgres 16 to 17) require pg_upgrade or logical replication cutover — this usually means downtime planning or a failover dance. Managed services handle this for you.

Connection pooling is a persistent gotcha. Postgres spawns a new OS process per connection. At 100+ concurrent connections you’ll hit performance degradation without PgBouncer. Managed services include connection pooling; self-hosted means you configure it yourself.

High availability without a managed service means Patroni or repmgr for automated failover — neither is trivial to operate.

For a solo founder running a side project or internal tool: the Docker Compose setup with daily backups to S3 is genuinely sufficient and takes an afternoon. For a production app with real revenue and users, budget time for PgBouncer, monitoring, and a tested backup restoration procedure before you call it done [5].

---

Pros and cons

Pros

• It’s the actual database. Not a fork, not a compatible alternative, not a wrapper — the same Postgres binary inside every major managed service [1]. Zero migration risk when switching providers.
• PostgreSQL License. Truly free for any use, commercial or otherwise. No usage restrictions, no commercial licensing required.
• Massive extension ecosystem. pgvector, PostGIS, timescaledb, pg_stat_statements, and hundreds more — install whatever you need, unlike managed providers with curated lists [5].
• Full configuration control. Tune shared_buffers, work_mem, wal_level, and kernel parameters to match your actual workload. Managed services abstract this away — sometimes helpfully, sometimes not [5].
• The math works for small teams. $7–8/month all-in versus $35–84/month managed. Over a year, that’s real money [2][4].
• No cold starts, no compute pausing. Unlike serverless database offerings that scale to zero, a self-hosted Postgres instance is always on [2].
• Proven at scale. 35+ years of production use. The reliability record is not theoretical [1].
• Data sovereignty. Your data stays on your server, in your jurisdiction, accessible only to you. Relevant if you’re in a regulated industry or handling sensitive customer data [3].

Cons

• You own the operations. Backups, TLS, failover, upgrades, monitoring — all yours. If you get this wrong, data loss is possible [5].
• No dashboard out of the box. You get a database, not a management UI. pgAdmin exists but requires separate setup. Managed services include web dashboards for queries, backups, and metrics.
• 4–8 hours/week of ongoing maintenance for a production instance [5]. During major version upgrades, more. That time has real cost.
• High availability is complex. Patroni or repmgr for automated failover. Neither is weekend-project territory. Managed services handle failover automatically [5].
• Connection pooling is your problem. PgBouncer is the standard solution; configuring it correctly for your workload takes experimentation.
• No built-in Supabase/Firebase extras. Self-hosting Postgres gives you the database. Auth, realtime subscriptions, REST APIs, storage — you build or bring those separately [3].
• VPS outages take you down. If your VPS provider has an outage, your database goes with it. Managed services with multi-AZ deployment have better availability SLAs — though one self-hoster ran two years serving tens of millions of daily queries without a meaningful incident [1].
• Security misconfigurations are your fault. An exposed pg_hba.conf, a weak password, or an open port 5432 to the public internet can be catastrophic. Managed services handle network isolation by default.

---

Who should use this / who shouldn’t

Self-host Postgres if:

• You’re running a side project, internal tool, or early-stage product where paying $50–80/month for RDS is a significant cost relative to revenue.
• You’re comfortable with (or willing to learn) basic Linux server administration and Docker.
• You need extensions your managed provider doesn’t support — pgvector, PostGIS, custom types.
• You’re running multiple small databases and managed-service pricing is hitting you per-database [2].
• Data residency or compliance requirements mean your data must stay in your own infrastructure.
• You want to understand what’s actually happening in your database rather than treating it as a black box.

Stay on a managed service if:

• You’re generating real revenue and downtime would directly cost you money. The $50/month Supabase or RDS bill is cheap insurance [3].
• Your team has no one comfortable with Linux server operations.
• You need the Supabase/Firebase bundle: auth, realtime, storage, REST APIs. Self-hosting Postgres gives you just the database [3].
• You’re growing fast and need read replicas, multi-AZ failover, or instant scaling without manual work.
• Your compliance team requires SOC 2 or ISO certification — managed providers have it; your self-hosted instance does not out of the box.

Skip both and use a focused managed-Postgres service (Neon, Railway, or similar) if:

• You want the developer experience of a managed service without AWS billing complexity.
• You’re comfortable with slightly higher cost than self-hosted in exchange for simplified ops.
• Railway’s $5/month hobby tier covers your workload — that’s practically self-hosted pricing with someone else handling operations [2].

---

Alternatives worth considering

• Supabase (self-hosted or managed) — Postgres plus auth, storage, realtime, REST, and a dashboard. The managed cloud is genuinely excellent. Self-hosting the full stack is complex — you’re operating Kubernetes, multiple microservices, and constant patching [3]. Not the same as self-hosting bare Postgres.
• MySQL / MariaDB — The other major open-source relational database. Smaller feature set than Postgres, historically faster for read-heavy workloads, but Postgres has largely closed that gap. Choose MySQL if your stack or team has existing expertise.
• SQLite — For single-server apps, embedded use, or low-concurrency workloads, SQLite is dramatically simpler. No server process, no network configuration, no connection pooling. Seriously consider it before reaching for Postgres if your app will run on one machine.
• Neon — Managed Postgres with a generous free tier, serverless scaling to zero, and Git-like branching for development databases. Significantly cheaper than RDS for intermittent workloads.
• PlanetScale — MySQL-compatible, developer-friendly, branch-based schema migrations. Not Postgres, but worth considering if the branching workflow appeals.
• AWS RDS / Aurora — The incumbent managed option. More configuration knobs than smaller providers, pay-per-resource billing, deep AWS integration. Expensive at scale [2].
• CockroachDB — Distributed SQL with Postgres-compatible syntax. Relevant if you need multi-region writes. Overkill for most use cases.

For a non-technical founder evaluating self-hosted Postgres: the realistic alternative is not RDS, it’s Railway (managed, $5/month starter) or Neon (managed, free tier generous). Self-hosted Postgres makes sense when you’re comfortable with a VPS and want full control, or when you’re running enough databases that per-database managed pricing hurts.

---

Bottom line

PostgreSQL is the database. Not a contender, not an alternative to consider — the foundation underneath most of the databases people are already paying for. Self-hosting it is genuinely viable for founders and small teams who are comfortable with a VPS and willing to own basic operations. One developer ran it for two years, tens of millions of queries daily, with 30 minutes of total incident time [1]. The cost math is unambiguous — $8/month versus $84/month is not a close call.

The honest caveat is that “self-hosted” comes with a real operational tax: 4–8 hours per week of maintenance, a tested backup procedure, TLS configuration, and connection pooling setup [5]. If that’s time you don’t have, or if your app generates revenue that makes downtime expensive, the managed services charging a premium for handling exactly those things are worth the money. But if you’re a founder paying $50–80/month to a managed service for a product that isn’t yet generating revenue — that bill is paying for someone else’s operational convenience, not a fundamentally better database.

If setting up the self-hosted instance is the blocker, that’s exactly what unsubbed.co’s parent studio upready.dev deploys for clients. One-time fee, done, you own the infrastructure.

---

Sources

1. Pierce Freeman — “Go ahead, self-host Postgres”. pierce.dev. https://pierce.dev/notes/go-ahead-self-host-postgres
2. Yannik Zeyer — “Why you need a self-hosted postgres DB”. medium.com. https://medium.com/@sophisticatedmemento/why-you-need-a-self-hosted-postgres-db-80c6104bac23
3. Vela / simplyblock — “Self-Hosting Supabase vs Managed Postgres: Control, Cost, and Complexity”. vela.simplyblock.io. https://vela.simplyblock.io/articles/self-hosting-supabase/
4. Alex Aslam — “Dockerized Databases on Your Terms: Self-Host PostgreSQL/MySQL Like a Pro”. dev.to. https://dev.to/alex_aslam/dockerized-databases-on-your-terms-self-host-postgresqlmysql-like-a-pro-without-the-3-am-panic-20ci
5. Antonio Di Pinto — “Managed vs. Self-Hosted PostgreSQL: Tradeoffs and When Each Makes Sense”. medium.com. https://medium.com/@antoniodipinto/managed-vs-self-hosted-postgresql-tradeoffs-and-when-each-makes-sense-d5c6109dde2d

Primary sources:

• Official website: https://www.postgresql.org
• GitHub mirror: https://github.com/postgres/postgres (20,310 stars)
• Documentation: https://www.postgresql.org/docs/devel/
• Downloads: https://www.postgresql.org/download/