Websites
Websites · Review

Supabase Review: The Firebase Alternative That Actually Sticks

A hosted Postgres database wearing a developer platform's clothes, and somehow that combination is the whole appeal.

March 22, 2024
8.8/ 10
Editor's Verdict - Recommended

A solid Postgres-based backend that respects your data instead of locking it up, with a few rough edges outside the core database.

A friend who'd spent two years on Firebase kept telling me to stop starting projects on it, and I ignored him twice before a pricing estimate for a document-heavy side project came back looking like a car payment. So I tried Supabase on the next thing I built, expecting the open-source Firebase alternative pitch to mean a thinner clone with worse documentation. The comparison it invites is useful right up until you start building, at which point the two turn out to be coming at the same problem from opposite ends, because Firebase hands you a proprietary NoSQL store wrapped in SDKs and Supabase hands you a full Postgres database with auth, storage, realtime and edge functions layered on top of it.

The first evening went faster than I'd budgeted for. I opened the dashboard, built three tables in the visual editor, and had REST and GraphQL endpoints answering queries against them before writing a line of application code, because the API gets generated from the schema the moment a table exists. Empty project to working prototype is a same-evening trip, and I've done it twice more since without the novelty wearing off.

I ran a standard pg_dump and had everything portable to any Postgres host on earth about forty seconds later.

My conversion happened later than that and I can date it precisely, to the afternoon I migrated the project back off Supabase purely to see how hard it would be. I ran a standard pg_dump, waited about forty seconds, and had everything portable to any Postgres host on earth, with no export wizard in the way and nothing held hostage behind a proprietary format. Three projects on, not having to worry about that is worth more to me than anything on the pricing page, and the reason is boring: foreign keys, joins, triggers and views are all just Postgres, so everything I already knew about relational databases came across intact, with no invented query language squatting between me and my own rows.

Row-level security took me longer to trust than it should have. Authorization lives in Postgres policies sitting next to the schema instead of scattered through application middleware, so the same rules hold whether a request arrives from the web app, a mobile client, or somebody poking the API directly with curl. I kept my old middleware checks running in parallel for about a month anyway, belt and suspenders, and it took an evening of reading through request logs before I admitted they'd been dead code the entire time. Once that clicked, the whole category of "did I remember to check permissions on this route" bugs stopped existing for me.

The SQL editor saves snippets, which sounds like a small thing until you have forty of them and stop rewriting the same three diagnostic queries every time something looks wrong at eleven at night.

Auth wires up in an afternoon for the paths most projects need, email, magic links and the usual OAuth providers. Custom SMTP setup is bad, with error messages written as riddles that tell you a send failed without telling you which credential they disliked, and I lost most of an evening to what turned out to be a trailing space in a hostname, which I am definately not over.

Edge Functions I've mostly stopped using, which is my one 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 pushed me toward other tools for anything on a hot path, and I've made my peace with treating Supabase as a spectacular database with benefits rather than a complete backend. The CLI is the opposite story, its migration handling and local Postgres setup are tidy enough that I've installed it on projects that have nothing to do with Supabase at all.

The free tier ships side projects rather than toy demos, with a proper Postgres instance, 500MB of storage and 50,000 monthly auth users, and one gotcha I've been caught by twice now: projects pause after a week of inactivity. Both times it happened mid-demo, on something I'd ignored for a month, and both times I had to talk over a loading spinner while it woke back up. $25 a month removes the pausing, which I now pay on anything I'd be embarrassed to have stall in front of someone.

Against Firebase you trade Google's infrastructure polish and its much more mature mobile-offline story for a database you own outright, and against assembling your own stack you trade a bit of control for a few weeks of setup you get back on day one. Realtime subscriptions are the piece I still can't size properly, they work well for chat and dashboard cases and they will happily eat database load if you broadcast tables indiscriminately, but nothing in the docs told me where that line sits and I've been too cautious to go looking for it in production. I keep meaning to build something deliberately chatty on a throwaway project just to find out where it falls over, and I keep building the sensible thing instead.

Reader Reviews

4.0
★★★★
3 reviews
5
33%
4
33%
3
33%
2
0%
1
0%
Leave your rating
rupay★★★★3 weeks ago

Row level security is the correct model and everyone still writing auth middleware in 2026 is doing it wrong, the policy lives with the schema, period. Write your policies before your tables exist and test them like code, not as an afterthought on ship day. The article undersells how good the local CLI workflow for this is.

goodygood_274★★★★★Oct 2024

Shipped my first real side project on the free tier, auth and database and all, without touching a server. The dashboard made sense to someone like me who's not a database person. It did pause after I ignored it for a month, which is fair enough honestly.

Gman8181★★★★★Jun 2024

It's Postgres with a nice dashboard. We had that, it was called pgAdmin and a five dollar VPS, and it didn't pause your database for inactivity like an arcade machine waiting for quarters. The pg_dump exit path is genuinely respectable though. Credit for that.