PostgreSQL Self-Hosted vs Managed: When to Build, When to Buy

The Question Everyone Avoids

Should I run my own PostgreSQL, or let someone else handle it?

The answer isn’t “it depends.” It absolutely depends. But most people guess wrong.

I’ve done both. Extensively. And I’ve learned that the “obvious” choice is often backwards.

My Journey (TL;DR: It’s Complicated)

2023: Self-hosted Postgres on my NAS. Felt smart. Saved $50/month.

2024: Had to restore a corrupted database at 3 AM. Learned I’d never tested backups. Panic.

2025: Switched everything to AWS RDS. Paid more, slept better.

2026: Moved critical databases back to self-hosted. But properly this time.

This isn’t a feel-good story about “building it right.” It’s about understanding the actual trade-offs.

Let’s Talk Cost (The Part That’s Wrong In Most Articles)

Everyone says “self-hosted is cheaper!” It’s not.

Self-Hosted PostgreSQL True Cost:

Infrastructure:
  - NAS or server:           $500-2000 (upfront, 5-year amortization = $8-40/mo)
  - Electricity:             $20-50/month
  - Network (backups):       $5-30/month
  - Your time (setup):       20 hours × $50/hr = $1000 (one-time)
  - Your time (maintenance): 2 hours/month × $50/hr = $100/month

Total: $135-220/month (after amortization)

AWS RDS Single-AZ (2 vCPU, 16GB RAM, gp3 storage):

  - Database instance:       $200-250/month
  - Storage (100GB):         $15-20/month
  - Backups (automatic):     Free (first 30 days retention)
  - Data transfer:           $0.02/GB egress (your app pays this)

Total: $215-270/month (variable)

These aren’t that different. But the nature of the cost is.

With self-hosted, you own the infrastructure. If you need more power, you buy a bigger NAS. With RDS, you get auto-scaling and you’re pinned to AWS pricing.

Here’s what nobody mentions: If something breaks with RDS, AWS fixes it. If something breaks with self-hosted Postgres, you fix it. That’s either “exciting” or “a nightmare” depending on the time of day.

Self-Hosted: When You Should Do It

Do it if:

1. You’re hosting multiple apps on one Postgres instance

   • Every small app on RDS costs $200+/month
   • One fat Postgres with 50 databases? $50/month electricity
   • This is where self-hosted wins decisively

2. You’re comfortable with operational responsibility

   • You’ve set up replication before
   • You know what pg_basebackup does
   • You don’t panic at “replication lag”

3. Your data is not “mission critical” in the strict sense

   • Your customer’s SaaS? Probably not
   • Your personal projects? Totally fine
   • Your company’s internal tools? Depends on the company

4. You want to avoid vendor lock-in

   • Leaving AWS is expensive and slow
   • Moving between self-hosted and another host? Just dump the database

5. Regulatory requirements force you

   • GDPR mandates data residency in EU
   • Your database is under direct control if it’s on your hardware

Don’t do it if:

• You work alone and hate being on-call
• Your data is critical to revenue
• You’re not comfortable with Linux administration
• You want “enterprise SLA” guarantees

Managed Postgres: The Hidden Costs

AWS RDS (and DigitalOcean, Google Cloud, etc.) are not simpler.

Things RDS doesn’t do:

• Automatic version upgrades — You have to schedule downtime. Major versions need testing.
• Query optimization — You’re on your own. RDS doesn’t rewrite your N+1 queries.
• Connection pooling — PgBouncer isn’t included. You add a separate service ($$$).
• Extensions — Some extensions aren’t available. You hit limitations you didn’t expect.

Things you’ll still need to learn:

• How to set up read replicas (complexity multiplies)
• How to backup/restore (their tools are clunky)
• How to monitor performance (CloudWatch is… rough)
• Why your database is slow (again, on you)

You’re not buying “I don’t have to think about the database.” You’re buying “AWS patches security updates and handles hardware failures.”

That’s valuable. But it’s not the same thing.

My Current Setup (Hybrid)

I’m doing both. Seriously.

Self-Hosted (NAS with ZFS):

• Nextcloud database
• Immich database
• Forgejo database
• Internal tools + monitoring

Managed (AWS RDS):

• SaaS-adjacent stuff (anything customer-facing)
• Payment processing related databases
• Anything with “uptime SLA” in the spec

This gives me:

• Cost efficiency for non-critical data
• Peace of mind for revenue-critical data
• Ability to test things locally without paying AWS

The key: I have a clear rule about which goes where.

Setting Up Self-Hosted Postgres Right

If you decide to do it, here’s what matters:

1. Use Persistent Storage (ZFS, RAID, Something Real)

# Bad: Database on single SSD
# Good: Database on RAID-1 SSD (NAS)
# Better: Database on ZFS with snapshot backups

# Check your setup
df -h /var/lib/postgresql
# Should say something like /dev/mapper/zfs_pool

2. Enable Streaming Replication

Single-node Postgres is a gamble. Do this:

-- On primary
ALTER SYSTEM SET wal_level = replica;
ALTER SYSTEM SET max_wal_senders = 3;
ALTER SYSTEM SET hot_standby = on;

-- Create a replication user
CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD 'secure_password';

Suddenly you have a standby replica that’s always up-to-date.

3. Backup Automation Is Non-Negotiable

#!/bin/bash
# Daily backup to NAS + offsite

pg_basebackup -h localhost -D /backups/postgres/$(date +%Y%m%d) -Ft -z

# Ship to offsite
restic backup /backups/postgres/...

# Clean up old backups (keep 30 days)
find /backups/postgres -mtime +30 -delete

4. Monitor Everything

# Install pg_stat_statements extension
CREATE EXTENSION pg_stat_statements;

# Monitor replication lag
SELECT slot_name, restart_lsn FROM pg_replication_slots;

# Watch connections
SELECT count(*) FROM pg_stat_activity WHERE state = 'active';

Setup Prometheus + Grafana. If you don’t know what your database is doing, you can’t fix it.

The Hybrid Approach (My Recommendation)

Here’s the practical middle ground:

1. Self-host for personal stuff (< $100/month infra cost)

   • Your own apps
   • Internal tools
   • Experiments

2. Managed for anything customer-facing

   • SaaS (even side-projects that make money)
   • Payment data
   • Anything with uptime guarantees

3. Test backups quarterly

   • Restore to a VM
   • Verify data integrity
   • Practice your recovery procedures

4. Document your procedures

   • How to restore from backup
   • How to failover to replica
   • Who to call if it breaks

This isn’t “the right answer.” It’s the balance between cost, reliability, and your stress level.

Questions To Ask Yourself

Before you decide, answer these honestly:

• How bad is downtime? If an hour of database downtime costs you money, use managed.
• How much data? Under 100GB? Self-host. Over 1TB? Probably managed.
• How comfortable are you at 3 AM? If “not at all,” managed wins.
• Can you restore a backup? Have you actually done it? If not, don’t self-host.
• Is this a learning project? Learning is valid! Self-host and break things.

The Version Upgrade Dance

This is where managed services actually shine, and I’ll admit it.

Self-hosted: You see “Postgres 16 is out!” and think “cool, maybe next year.”

Managed (AWS): They notify you. Give you a window. Auto-upgrade with automatic rollback if it breaks.

For production systems, this alone might be worth the cost.

Common Mistakes I Made (So You Don’t)

1. Assumed backups worked without testing them

   • I had 18 months of “backups” that were corrupted
   • Found out when I needed them
   • Pain

2. Didn’t set up replication

   • Single point of failure for critical data
   • One bad sector = weeks of detective work

3. Used the same hardware for both Postgres + other stuff

   • Database I/O starved other services
   • Impossible to debug

4. Didn’t monitor replication lag

   • Replica was weeks behind primary
   • Thought I had a backup (I didn’t)

5. Changed Postgres settings without testing

   • shared_buffers = 80% of RAM sounds good until it’s not
   • Test in a VM first

What I Wish Someone Told Me

Self-hosting is viable. It’s also boring work.

The appeal fades after you’ve restored a database at 3 AM for the third time. The cost savings evaporate when you factor in your time.

But there’s a sweet spot: Use managed for critical stuff. Use self-hosted for everything else. Test both regularly.

That’s it. That’s the whole philosophy.

Your Action Plan

Pick your first database. Ask yourself:

• Is this customer-facing? → Managed
• Is this just for me? → Self-hosted
• Do I actually have time to maintain it? → Factor that in

Then set up backups. Test them. Document the procedure.

In 6 months, you’ll have a mental model that actually works instead of just hoping.

Have thoughts on this? Running Postgres yourself? Lost data and learned a hard lesson? Let me know.

Tested on Postgres 14, 15, and 16 | May 2026 | AWS RDS us-east-1 and self-hosted ZFS