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.

Supabase is not a database

Supabase runs on PostgreSQL, but it's a stack of services around it:

• Postgres – the actual database
• Auth – user signup, login, JWT tokens
• Realtime – live updates over websockets
• Storage – an S3-style file store
• Edge Functions – serverless functions
• Studio – dashboard + auto-generated REST/GraphQL API

So "self-host Postgres or use Supabase" compares a plain database to a full backend. The honest question: do you need those extra layers, or just the database underneath them?

A quick test:

• You use Supabase Auth, Storage, and Realtime → Supabase earns its place.
• You use one of them → it's replaceable.
• You use none and treat it as "Postgres with a nice dashboard" → you want plain Postgres.

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 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

The lock-in point decides it for many teams. Your data is standard Postgres in every option (pg_dump portable). The lock-in is everything else: Auth tokens, Storage paths, Supabase-specific RLS policies, Edge Function code. The more Supabase-specific features you adopt, the harder the exit.

When each option wins

Pick managed Supabase when:

1. You're starting a new app and want auth, storage, and realtime working today.
2. You'll 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.
2. You're ready to run and update a multi-container stack.
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.

The honest summary

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

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

---

I write about this stuff while building Hostim, a platform with managed Postgres built in. The full version of this post – with Docker Compose config and backup commands – is on the Hostim blog.