Supabase vs PostgreSQL: What Supabase Adds and When to Skip It (2026)
Supabase is PostgreSQL with a backend bolted on. Every Supabase project is a real Postgres database; the difference is the layers around it — authentication, realtime websockets, file storage, edge functions and a web dashboard with an auto-generated API. Plain PostgreSQL is the database on its own.
So 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?
Is Supabase open source, and is PostgreSQL?
Both are, but under different licences and with a different catch.
PostgreSQL ships under the PostgreSQL Licence, a permissive BSD-style licence. There is one Postgres, anyone can run it, and no company controls the project.
Supabase is a company that publishes its platform on GitHub — the main supabase/supabase repository is Apache-2.0, and the pieces around Postgres are separate open-source projects: PostgREST (the REST API), GoTrue (auth), Realtime (an Elixir server), Storage, pg_graphql and postgres-meta. You can run all of it yourself with Docker Compose.
The catch is not the licence, it is the operational gap. Self-hosted Supabase means running roughly ten containers — Postgres, PostgREST, GoTrue, Realtime, Storage, Kong, Studio, the meta API and the imgproxy/analytics extras — and keeping them upgraded together. Plain Postgres is one container and one upgrade path.
So "open source" answers the ownership question, not the effort question:
- Can I leave? Yes, in every option — the data is standard Postgres.
- Can I run it myself? Yes, but self-hosted Supabase is a platform to operate, not a database.
- Do I want to? Only if you actually use the layers. See the test below.
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:
- You are starting a new app and want auth, storage, and realtime working today.
- You will 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 deployment.
- You are ready to run and update a multi-container stack (Postgres, GoTrue, Realtime, Storage, Kong, Studio).
- 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.
If none of the three fits, Supabase Alternatives compares Firebase, Appwrite, PocketBase, Neon and others side by side.
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
Frequently asked questions
Is Supabase just PostgreSQL?
No. Every Supabase project runs a real PostgreSQL database, but Supabase adds authentication (GoTrue), realtime websockets, S3-style file storage, edge functions, and a dashboard with an auto-generated REST and GraphQL API. If you use none of those layers, you are running Postgres with extra services attached.
What is the difference between Supabase and PostgreSQL?
PostgreSQL is a database engine. Supabase is a backend platform built on top of that engine. The database itself is the same — the same SQL, the same extensions, the same pg_dump. The difference is the auth, storage, realtime and API services Supabase runs alongside it, and the fact that Supabase is a hosted product with a bill.
Is Supabase open source compared to PostgreSQL?
Both are open source, under different licences. PostgreSQL uses the permissive PostgreSQL Licence and is run by a community, not a company. Supabase publishes its platform on GitHub under Apache-2.0, with components such as PostgREST, GoTrue, Realtime and Storage as separate open-source projects. You can self-host either, but self-hosted Supabase means operating around ten containers instead of one.
Is Supabase faster than plain PostgreSQL?
No. It is the same PostgreSQL engine, so raw query performance is the same at equal hardware. What differs is what sits in front of it: PostgREST adds an HTTP hop that a direct database driver does not have, and connection pooling settings differ per plan. If you query Postgres directly from your backend in both setups, expect the same numbers.
When should I use plain Postgres instead of Supabase?
When your application already handles its own authentication and business logic and you mainly need a reliable database. You get a simpler cost shape, almost no lock-in, and one service to operate instead of a stack. If you use at least two of Supabase Auth, Storage and Realtime, Supabase earns its place.
Can I migrate from Supabase to self-hosted or managed Postgres?
The data moves easily — it is standard PostgreSQL, so pg_dump and pg_restore are enough. What does not move is everything built on the Supabase layers: Auth users and JWT settings, Storage object paths, Row Level Security policies written against auth.uid(), and Edge Function code. The more of those you adopted, the longer the migration takes.
Is self-hosted Supabase worth it?
Only if you want the whole feature set and need full data ownership or on-prem deployment. You take on updating a multi-container stack (Postgres, GoTrue, Realtime, Storage, Kong, Studio) and running your own backups. If the goal is just to stop paying for a hosted database, plain managed or self-hosted Postgres is far less work.
Does Supabase lock you in?
Partly. The rows never lock you in — they are standard Postgres. The lock-in is in the surrounding layers: auth tokens and user tables, storage paths, RLS policies written for Supabase, and Edge Functions. Adopting one of these is usually reversible; adopting all four is a rewrite.
Last updated: September 2026.