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:
- You're starting a new app and want auth, storage, and realtime working today.
- You'll genuinely use at least two of those features.
- You prefer to pay for convenience and not run infrastructure.
Pick self-hosted Supabase when:
- You want the Supabase feature set but need full data ownership or on-prem.
- You're ready to run and update a multi-container stack.
- Compliance or cost at scale justifies the extra ops work.
Pick plain Postgres (managed or self-hosted) when:
- You mainly need a reliable database, and your app already handles auth and logic.
- You want minimal lock-in and a simple, predictable cost.
- 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 .
SOCIAL SHARE CARD GENERATOR