Question 1

Is Supabase just hosted Postgres, or something more?

Accepted Answer

Supabase is a Backend-as-a-Service (BaaS) built around Postgres — you get the database plus PostgREST (auto-generated REST API from your schema), Realtime (Postgres LISTEN/NOTIFY + WebSocket subscriptions), Auth (JWT-based with social providers), Storage (S3-compatible), and Edge Functions (Deno). It's Postgres under the hood, but the "Supabase value" is the bundled application layer that lets frontend teams build full-stack apps without dedicated backend engineers.

Question 2

Supabase or self-managed Postgres — how to decide?

Accepted Answer

Supabase wins for: (a) early-stage / MVP products where time-to-market dominates, (b) frontend-led teams without backend engineering capacity, (c) workloads where PostgREST + Realtime + Auth are the dominant value, (d) Row Level Security (RLS) is the application authorization model. Self-managed Postgres wins for: (a) workloads at scale where Supabase pricing exceeds DIY economics, (b) custom backend code (Node/Go/Rust services) that don't need PostgREST, (c) on-prem / regulatory requirements that disqualify Supabase Cloud, (d) Postgres features Supabase restricts (custom languages, certain extensions).

Question 3

PostgREST auto-API — does it really work?

Accepted Answer

Yes, for CRUD-shaped workloads. PostgREST generates a REST API from your Postgres schema with row-level filtering, pagination, embedding (joins via foreign-key resolution), and full PostgREST query syntax. Combined with RLS, it's a complete authorization model — your frontend can hit Supabase directly without a backend layer. Where it falls apart: complex business logic that doesn't map to CRUD, stored-procedure-heavy patterns, custom validation logic. For those, you write Edge Functions or run a separate backend service alongside Supabase.

Question 4

Realtime subscriptions — Supabase vs raw Postgres LISTEN/NOTIFY?

Accepted Answer

Supabase Realtime wraps Postgres LISTEN/NOTIFY + WAL replication and exposes it via WebSocket subscriptions to frontend clients. The value: you don't build the WebSocket gateway, fanout layer, or auth integration yourself. For raw Postgres deployments wanting real-time, you need to build that infrastructure (Hasura, custom Node.js WebSocket layer, or Apache Kafka + Pulsar). For small-to-medium scale where Supabase's Realtime fits the budget, it's a huge time-saver. For larger scale where the Supabase Realtime cost-per-connection adds up, building your own may make sense.

Question 5

Row Level Security (RLS) — Supabase makes it usable?

Accepted Answer

RLS is a native Postgres feature, not Supabase-specific. Supabase's contribution is making RLS the default authorization model — every table has policies, the auth context (auth.uid()) is automatically set per request from the JWT, and the dashboard makes policy authoring approachable. You can do exactly the same on self-managed Postgres but you have to wire the auth context yourself. For teams comfortable with SQL but less so with backend auth-flow code, Supabase's RLS-first approach is meaningfully easier.

Question 6

Self-managed Postgres → Supabase migration?

Accepted Answer

Usually straightforward — Supabase IS Postgres, schema and queries port directly. The work is in adopting Supabase patterns: writing RLS policies for tables that previously relied on application-tier auth, replacing custom backend code with PostgREST + Edge Functions where possible, migrating realtime fan-out to Supabase Realtime. We typically see migrations driven by team-size constraints (shrinking backend team) or product velocity (frontend team wants direct DB access).

Question 7

Supabase → self-managed Postgres migration?

Accepted Answer

More common as Supabase deployments scale. Triggers: cost growth at scale, regulatory / data-residency requirements, custom features that Supabase doesn't support. Migration: data dump/restore is trivial (same Postgres), the real work is rebuilding the Supabase application layer — PostgREST → custom API service, Realtime → custom WebSocket layer or Hasura, Auth → Auth0 / Cognito / custom, Storage → S3 direct or MinIO. We see this migration most often at the 1k-10k MAU scale where Supabase economics tip.

Dimension	PostgreSQL (self-managed / Aurora / RDS)	Supabase
Category	Relational database	Backend-as-a-Service (BaaS) built on Postgres
Auto-API	None native — PostgREST or Hasura as add-ons	PostgREST built-in, generated from schema
Realtime	LISTEN/NOTIFY + custom WebSocket layer	Native — Realtime WebSocket subscriptions managed
Auth	External (Auth0, Cognito, Clerk, custom)	Built-in JWT-based with social providers + email/password
Storage	External (S3, GCS, MinIO direct)	S3-compatible Storage bundled with policies + RLS integration
Edge functions	External (Cloudflare Workers, Lambda, Cloud Run)	Built-in Edge Functions (Deno runtime)
RLS integration	Native Postgres feature — manual wiring of auth context	First-class — auth.uid() automatically set from JWT
Extension support	Full Postgres ecosystem (200+ extensions)	Curated subset — pgvector, PostGIS, pg_partman, TimescaleDB available
Cost model	Per-instance (Aurora/RDS) or per-resource (self-managed)	Per-project tier (Free / Pro / Team / Enterprise) + usage
Best for	Scale, custom backend code, full Postgres feature surface	Early-stage products, frontend-led teams, MVP velocity, RLS-first auth

PostgreSQL vs Supabase

Feature matrix

When PostgreSQL wins

When Supabase wins

Common questions

Need a Postgres-vs-Supabase decision?