A solid Postgres-based backend that respects your data instead of locking it up, with a few rough edges outside the core database.
Supabase pitches itself as an open-source Firebase alternative, and the comparison is useful right up until you start building, at which point it's clear the two solve the same problem from opposite directions. Firebase gives you a proprietary NoSQL store wrapped in SDKs. Supabase gives you a real, full-fat Postgres database and layers auth, storage, realtime, and edge functions on top, a stack you can peel back any time you'd rather just talk SQL.
Postgres is the single best decision in the product, and I can date my conversion precisely: the afternoon I migrated a project off Supabase with a standard `pg_dump`. No export wizard, no data held hostage, no lock-in tax. One command, and everything I'd built was portable to any Postgres host on earth. I've spent three projects since then not worrying about that, and not worrying is worth more than any feature on the pricing page. Foreign keys, joins, triggers, views, everything you already know about relational databases transfers directly, with no proprietary query language squatting between you and your data.
“I migrated a project off it with a standard pg_dump. No export wizard, no lock-in tax.”
Row-level security deserves its own paragraph, because it rewired how I write apps. Authorization lives in Postgres policies next to the schema, not scattered through application middleware, so the same rules hold whether a request comes from the web app, a mobile client, or someone poking the API directly. I'll be honest about the trust curve: I kept my old middleware checks running in parallel for a month, like a man wearing a belt and suspenders, before admitting the policies had made them dead code. Once it clicked, the entire category of "did I remember to check permissions on this route" bugs stopped existing for me.
The dashboard makes all of it approachable, visual table editor, SQL editor with saved snippets, and auto-generated REST and GraphQL APIs that make a new table queryable the moment it exists. Empty schema to working prototype is a same-evening trip.
Auth wires up in an afternoon for the normal paths, email, magic links, the usual OAuth providers. The uncommon paths are bumpier: custom SMTP setup threw me error messages worthy of a riddle, and a couple of session-refresh edge cases took more trial and error than the docs prepared me for.
Edge Functions I've mostly stopped using, which is my one real heresy about this platform. They're Deno-based serverless compute, fine for webhooks and scheduled jobs, but the cold starts and the local dev friction mean I reach for other tools for anything hot, and I've made my peace with treating Supabase as a spectacular database with benefits rather than a complete backend. The CLI's migration and local Postgres handling, in contrast, is clean enough that I've adopted it even on non-Supabase projects.
The free tier ships real side projects, a proper Postgres instance, 500MB storage, 50,000 monthly auth users, with one gotcha: projects pause after a week of inactivity, which has embarrassed me during more than one demo of a thing I'd ignored for a month. $25 a month removes the pausing. Realtime subscriptions work well for chat-and-dashboard cases and will happily eat database load if you broadcast tables indiscriminately.
Against Firebase, you trade Google's infrastructure polish and mobile-offline maturity for a database you own outright. Against rolling your own stack, you trade some control for weeks of setup you get back immediately. I've now defaulted to it for three straight projects, and the `pg_dump` escape hatch is doing most of the convincing.