Supabase PostgreSQL platform

Supabase gives each project a full, dedicated PostgreSQL database and surrounds it with platform services: Auth, Storage, Realtime, auto-generated REST and GraphQL APIs (PostgREST), Edge Functions, and the Supavisor connection pooler. The database is real PostgreSQL — you can connect with any client and use ordinary extensions — but the security model and day-to-day operations are shaped by the platform. For positioning against other options, see the cloud service map.

What the platform includes

• A complete PostgreSQL instance per project, with direct connection strings alongside pooled ones.
• Auth integrated with the database: user identities live in auth.users, and JWT claims are available inside SQL.
• Auto-generated data APIs that expose schema tables to browsers and mobile clients directly.
• Realtime push built on PostgreSQL logical replication.
• Storage and Edge Functions for files and server-side logic close to the database.

This bundling is the reason to choose Supabase: one platform replaces a backend layer. It is also the main thing to accept — the more of Auth, Storage, Realtime, and the APIs you adopt, the more your application couples to Supabase-specific schemas and services.

RLS is the security boundary

Because browser clients can reach tables through the auto-generated API, row-level security is not a hardening option — it is the security model:

ALTER TABLE notes ENABLE ROW LEVEL SECURITY;

CREATE POLICY "users can read their own notes"
ON notes FOR SELECT
USING (user_id = auth.uid());

CREATE POLICY "users can insert their own notes"
ON notes FOR INSERT
WITH CHECK (user_id = auth.uid());

auth.uid() reads the user id from the request's JWT, so the frontend can query through the API while the database enforces ownership. Three rules keep this safe:

1. Enable RLS on every table exposed through the API, including new tables added later — the API exposes what the schema exposes.
2. Test policies from the anonymous and authenticated roles, not just with the dashboard's service connection.
3. Never ship the service_role key to a client; it bypasses RLS entirely.

Differences to accept

• Backup and PITR depend on your plan. The free plan has no automatic backups or PITR — see the current numbers in the free PostgreSQL guide — and paid tiers differ in retention and restore granularity. Confirm the backup documentation matches your RPO before committing data.
• Connection budget is platform-shaped. Direct connections are limited; serverless and high-concurrency clients go through Supavisor, whose transaction-pooling mode restricts session-level features such as prepared statements. Test your driver and ORM against the pooled string, not only the direct one.
• Realtime consumes database resources. It streams changes via logical replication, so high-churn tables and large publications create real WAL and replication load on the same instance serving your queries.
• Exit requires unwinding platform pieces. pg_dump gets your data out, but Auth users, Storage objects, Realtime subscriptions, and Edge Functions are platform services that a dump does not capture.

Validate before production

1. RLS enabled and policy-tested on every API-exposed table, from both anonymous and authenticated contexts.
2. Backup, PITR, and restore granularity confirmed against the plan you actually pay for, with one real restore drill.
3. Driver, ORM, and migration tooling tested against the pooled connection string, including prepared-statement behavior.
4. Realtime load rehearsed on production-shaped write churn.
5. An export drill that covers pg_dump plus a plan for Auth, Storage, and functions.

For pooling, monitoring, and recovery drills that apply on any platform, see the production stack guide.