Supabase

What Supabase does

Supabase gives each project its own PostgreSQL database and builds the rest of a backend around it. PostgREST turns your tables into a REST API, the pg_graphql extension adds a GraphQL API, and the Realtime server streams inserts, updates and deletes to clients over websockets, alongside broadcast messages and presence. Supabase Auth handles sign-up and sign-in, Storage keeps files in S3-compatible storage, and Edge Functions run server-side TypeScript on Deno. The Studio dashboard ties it together with a table editor, SQL editor and settings.

The project describes its goal as delivering the features of Firebase using open source tools, but it is deliberately not a one-to-one copy. The biggest difference is the data model: you work with relational tables, SQL and Postgres extensions rather than a document store.

Security and access control

Authorization is done in the database. Auth issues JSON Web Tokens, and when a client calls the generated APIs with that token, Postgres Row Level Security policies decide which rows the user can read or change. User accounts live in a dedicated schema of the same database, so you can reference them from your own tables with foreign keys and triggers. Supported sign-in methods include email and password, magic links, one-time passwords, social providers, SSO and any OAuth2 or OIDC-compatible provider you configure.

The flip side is that security depends on writing correct RLS policies for every table the client can reach; a table without a policy is a common mistake to check for.

Moving from Firebase

Supabase publishes guides and scripts for moving Firebase Auth users (including their password hash parameters, so users keep their passwords), Firestore collections and Cloud Storage files. The Firestore tool copies each collection into one Postgres table with basic column types or jsonb, so nested data usually needs remodeling into related tables. Firebase Auth can also be connected as a third-party provider while you migrate.

Self-hosting Supabase

The official route is Docker Compose, using configuration kept in the main repository. The documentation lists a minimum of 4 GB RAM, 2 CPU cores and 40 GB of SSD storage, with 8 GB and 4 cores recommended. The stack includes Postgres, Studio, an API gateway, Auth, PostgREST, Realtime, Storage, imgproxy, postgres-meta, Edge Runtime and the Supavisor connection pooler; you can remove services you do not need. Logging and analytics (Logflare and Vector) are optional extras. Kubernetes deployments are community-maintained.

A self-hosted install runs a single project, and most settings are environment variables. The documentation lists what is not available: branching, advanced metrics, managed backups and point-in-time recovery, analytics and vector buckets, ETL and the Management API. Tested Docker snapshots are published about once a month, self-hosted Supabase sends no telemetry, and support comes from the community.

Hosted version

Supabase’s hosted platform has a Free plan and paid plans. Free projects are paused after a week of inactivity and you can have two active at once. Auth usage on paid plans is billed by monthly active users.

Limitations

The self-hosted stack is many containers and needs a reasonably sized server. Self-hosters give up multi-project management, branching and managed backups, so backups and upgrades are your job. Teams coming from Firestore have to design a relational schema and RLS policies, which takes real work for apps with deeply nested documents.

Who it suits

Supabase fits teams that want a Firebase-style developer experience but prefer SQL and Postgres, value being able to take their database elsewhere, and want the option to self-host later. It is the most complete general-purpose choice in this category; if you need a single small binary instead, look at PocketBase.