Supabase gives you a Postgres database and wraps the things most applications need around it: a REST and GraphQL API generated from your schema, authentication with email, magic links and around twenty OAuth providers, file storage, realtime subscriptions over websockets, and edge functions for server-side logic. The pitch is that you get the productivity of a backend-as-a-service without the lock-in, because underneath it is an ordinary Postgres database you can dump, migrate or self-host.
That last point is the substantive difference from the alternatives. Supabase is open source, the whole stack can be run with Docker on your own machine, and the database is standard Postgres rather than a proprietary store with a SQL-like interface. Your schema, your extensions, your indexes, your triggers. If you outgrow the hosted product or the company disappears, the exit path is a pg_dump rather than a rewrite. Teams who have been burned by a proprietary backend before tend to weigh this heavily.
The security model is worth understanding before you build on it, because it is where most of the learning curve sits. Supabase exposes your database to the browser directly and relies on Postgres row level security to decide who can read and write what. Written properly, this is elegant: authorisation rules live next to the data and apply no matter which client connects. Written carelessly, you have published your database. The policies are SQL, they need testing, and the default of an unprotected table is something you must actively fix rather than something the platform fixes for you.
Day to day the developer experience is good. The dashboard includes a table editor, a SQL editor, a log viewer and a schema visualiser. Migrations can be managed through the CLI and checked into version control. Client libraries exist for JavaScript, Flutter, Swift, Python and others, and the JavaScript one is typed from your actual schema, so a renamed column becomes a compile error rather than a runtime surprise. Realtime works by listening to the Postgres write-ahead log, which means live-updating UI without you running a separate message broker.
Who it suits: teams who want to move quickly without giving up their data, solo developers who do not want to write another authentication flow, and anyone who already knows SQL and would rather use it than learn a proprietary query language. Who should be careful: teams without anyone comfortable in Postgres, since row level security is not optional, and applications whose access patterns are a poor fit for relational storage.
