Self-Host Postgres or Use Supabase? Here's How to Decide

Short answer first: use Supabase if you want Postgres plus auth, realtime, storage, and a dashboard as one managed bundle. Self-host Postgres – or use a managed Postgres – if you mostly need a database and your app already handles its own auth and logic. The choice is not really "Postgres vs Supabase". It's whether you need the extra layers Supabase puts on top of Postgres.

This post gives you a clear way to decide, a side-by-side table, and the cases where each option is the right one.

---

Supabase is not a database

This is the part that confuses the comparison. Supabase runs on PostgreSQL, but Supabase is a stack of services around it:

• Postgres – the actual database
• Auth – user signup, login, and JWT tokens
• Realtime – live updates pushed to clients over websockets
• Storage – an S3-style file store with access rules
• Edge Functions – serverless functions
• Studio – a web dashboard and auto-generated REST/GraphQL API

So when people ask "should I self-host Postgres or use Supabase", they are comparing a plain database to a full backend. The honest question is: do you need those extra layers, or just the database underneath them?

---

Do you actually use the Supabase features?

Be honest about which parts you use. Many teams pick Supabase, then build their own auth anyway, never touch realtime, and store files somewhere else. If that's you, you are paying in lock-in for features you don't run.

A quick test:

• You use Supabase Auth, Storage, and Realtime → Supabase earns its place.
• You use one of them → it is replaceable. Check what it would take to drop it.
• You use none and treat Supabase as "a Postgres with a nice dashboard" → you want plain Postgres.

---

Who owns your data and backups?

On managed Supabase, your data lives in their project and you rely on their backup schedule and retention. That is fine for many teams, but you should know the limits of your plan – on smaller tiers, point-in-time recovery and longer retention are paid add-ons.

With self-hosted Supabase or plain Postgres, backups are yours to run and yours to keep. More work, full control. On a managed Postgres (including Hostim), backups are handled for you while the database stays a standard Postgres you can dump and move at any time.

---

What does it cost as you scale?

A managed backend looks cheap at signup and grows with usage – database size, bandwidth, and add-ons all meter upward. We wrote about this pattern in Usage-Based Pricing: Why Your Bills Creep Up and Cloud Rent in Action. The same logic applies here: bundled convenience is worth paying for only if you use the bundle.

Plain Postgres has a simpler cost shape: you pay for the database, not for five services attached to it.

---

Migration lock-in: how hard is it to leave?

This is the deciding factor for many teams.

• Your data is standard Postgres in every option, so the rows themselves are portable with pg_dump.
• The lock-in is in everything else: Auth tokens, Storage paths, Row Level Security policies written for Supabase, and any Edge Function code. The more Supabase-specific features you adopt, the harder the exit.

Plain Postgres has almost no lock-in. That is its main long-term advantage.

---

Side-by-side comparison

Factor	Supabase (managed)	Self-hosted Supabase	Plain Postgres (managed or self-hosted)
Database engine	PostgreSQL	PostgreSQL	PostgreSQL
Built-in auth	Yes	Yes	No (bring your own)
Realtime / websockets	Yes	Yes	No
File storage	Yes	Yes	No
Dashboard + auto API	Yes	Yes	No (use any SQL client)
Backups	Managed (limits by plan)	You manage	Managed (Hostim) or you manage
Cost shape	Metered, grows with usage	Server cost + your time	Database only
Self-host effort	None	High (many containers)	Low–medium
Lock-in	Medium–high	Medium	Very low

---

When each option wins

Pick managed Supabase when:

1. You are starting a new app and want auth, storage, and realtime working today.
2. You will genuinely use at least two of those features.
3. You prefer to pay for convenience and not run infrastructure.

Pick self-hosted Supabase when:

1. You want the Supabase feature set but need full data ownership or on-prem deployment.
2. You are ready to run and update a multi-container stack (Postgres, GoTrue, Realtime, Storage, Kong, Studio).
3. Compliance or cost at scale justifies the extra ops work.

Pick plain Postgres (managed or self-hosted) when:

1. You mainly need a reliable database, and your app already handles auth and logic.
2. You want minimal lock-in and a simple, predictable cost.
3. You value boring, standard Postgres you can move anywhere.

---

Running Postgres without the Supabase layer

If you land on plain Postgres, you have two clean paths.

Self-host with Docker Compose:

services:
  db:
    image: postgres:17
    restart: always
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: app
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"

volumes:
  pgdata:

Then connect with a standard URL and schedule your own backups:

# connection string
postgres://app:change-me@localhost:5432/app

# daily backup
pg_dump "postgres://app:change-me@localhost:5432/app" > backup-$(date +%F).sql

You own the server, the updates, the disk, and the backups.

Or use managed Postgres. On Hostim, PostgreSQL is provisioned next to your app with backups, metrics, and a connection string ready to paste – no multi-container stack to maintain, and still a plain Postgres you can pg_dump and take with you. Not sure which engine fits at all? See Which Database Should You Self-Host?.

---

The honest summary

Supabase is a strong choice when you use its full stack. The moment you only want the database underneath it, you are paying in cost and lock-in for layers you don't run. Match the tool to what you actually use:

• Need a backend → Supabase.
• Need a backend you fully own → self-hosted Supabase.
• Need a database → plain Postgres, managed or self-hosted.

👉 Spin up a managed Postgres on Hostim – free tier, no card

Last updated: June 2026.