A genuinely solid Postgres-based backend that respects your data instead of locking it up, held back only by a few rough edges outside the core database.
Supabase pitches itself as an open-source Firebase alternative, and that comparison is useful right up until you actually start building on it, at which point it becomes clear the two products solve the same problem from opposite directions. Firebase gives you a proprietary NoSQL document store with a mountain of client SDKs wrapped around it. Supabase gives you a real, full-fat Postgres database and builds auth, storage, realtime subscriptions, and edge functions on top of it as a layer you can peel back whenever you want to just talk to SQL directly.
That Postgres foundation is the single best decision in the whole product. Anything you already know about relational databases, foreign keys, joins, views, triggers, row-level security policies, transfers directly, and none of it is hidden behind a proprietary query language you have to relearn. I've migrated a project off Supabase entirely with a standard `pg_dump`, no export wizard, no vendor lock-in tax, and that alone puts it ahead of most hosted backend platforms before you even get to the features.
“I migrated a project off it with a standard pg_dump. No export wizard, no lock-in tax.”
Row-level security is where Supabase earns its keep for anything beyond a toy project. Instead of writing authorization logic in application code, you write Postgres policies that live next to the schema itself, and the same rules apply whether the request comes from your web app, a mobile client, or someone poking at the API directly. It took me longer to learn than a typical middleware auth check, but once it clicked, entire categories of "did I remember to check permissions here" bugs stopped being possible.
The dashboard is the part that actually makes the database approachable for people who don't want to live in a terminal. A visual table editor, a SQL editor with saved snippets, and an auto-generated API explorer all sit on top of the same Postgres instance, and the auto-generated REST and GraphQL APIs mean you can start querying a new table the moment you create it, no backend code required. It's genuinely one of the faster paths from an empty schema to a working prototype I've used.
Auth covers the basics well, email and password, magic links, and a solid list of OAuth providers, and it's straightforward to wire up in an afternoon. Where it gets shakier is in the less common flows: I ran into confusing error messages during a custom SMTP setup, and a few of the auth edge cases around session refresh took more trial and error than the docs prepared me for. None of it was a dead end, but it wasn't the same one-afternoon smoothness as the core setup.
Edge Functions, Supabase's serverless compute built on Deno, work well for what they're aimed at: webhooks, scheduled jobs, and small bits of server-side logic that don't need a full backend. Cold starts are noticeable if you're expecting Vercel-level snappiness, and the local development story for functions still has some friction compared to the rest of the CLI, which otherwise handles migrations and local Postgres instances cleanly.
The free tier is generous enough to build and ship a real side project on without hitting a paywall in week one, a proper Postgres database, 500MB of storage, and 50,000 monthly active users on auth, though projects pause after a week of inactivity on the free plan, which has caught me off guard more than once coming back to a demo after a slow month. The Pro tier at $25 a month removes the pausing and raises the limits enough for most small production apps.
Realtime subscriptions, built on Postgres's logical replication, work well for straightforward cases like a chat app or a live dashboard, but they can get expensive in database load if you're not deliberate about which tables you're broadcasting changes from. It's a feature that rewards understanding what's happening underneath it rather than just flipping it on everywhere.
Compared to Firebase, you're trading some of Google's global infrastructure polish and its more mature mobile SDKs for a database you actually own and can query with tools you already know. Compared to rolling your own Postgres plus auth plus storage stack, you're trading a chunk of control for weeks of setup time you get back immediately. For most small-to-midsize projects that don't need Firebase's specific mobile-offline strengths, that trade favors Supabase clearly.