Back to DevLog

Why I Chose Supabase Over Firebase

3 min read

I used Firebase for two years before switching everything to Supabase. Here's why, and what I learned in the process.

What Firebase does well

Let me be fair — Firebase is excellent in many ways. The real-time database is dead simple. Authentication is turnkey. Hosting is fast. If you're building a mobile app and want to ship fast, Firebase is a great choice.

But I'm not building mobile apps. I'm building SaaS products with complex data models, multi-tenant architectures, and the need to write actual SQL queries. And that's where Firebase started to hurt.

The breaking points

1. No real database

Firestore is a document database. It's great for simple key-value lookups, but the moment you need joins, aggregations, or complex queries, you're fighting the data model. I was denormalizing everything, duplicating data across collections, and writing cloud functions to keep things in sync. That's not a database — that's a workaround.

2. No Row Level Security

Firebase has security rules, and they're fine for simple cases. But Supabase's RLS is PostgreSQL policies — real, SQL-based access control that runs at the database level. I can write a policy once and know that no API route, no server action, no direct query can bypass it. With Firebase, I had to manually check permissions in every cloud function.

3. Vendor lock-in

Firebase is deeply integrated with Google Cloud. Your data lives in Google's proprietary format. Exporting is possible but painful. With Supabase, my data is in PostgreSQL — the most portable database format on earth. If Supabase disappeared tomorrow, I could spin up a Postgres instance and keep running.

4. Pricing predictability

Firebase pricing is usage-based in a way that's hard to predict. Document reads, writes, and deletes all cost money, and a badly written query can spike your bill overnight. Supabase has clear tier-based pricing. I know what I'm paying each month.

What Supabase gives me

  • PostgreSQL — real SQL, real joins, real aggregations, real constraints
  • Row Level Security — database-level access control, not application-level
  • Auth — built-in auth with email, OAuth, and magic links
  • Real-time — PostgreSQL's LISTEN/NOTIFY for real-time subscriptions
  • Edge Functions — Deno-based serverless functions for custom logic
  • Storage — S3-compatible file storage with RLS policies
  • Dashboard — table editor, SQL editor, and log viewer in one place

The migration

Moving 6 projects from Firebase to Supabase took about three weeks. The hardest part was redesigning the data models from document-based to relational. But once the schemas were in place, everything got simpler. Queries that required three Firestore calls and a cloud function became a single SQL join.

The honest downsides

Supabase isn't perfect. The real-time system isn't as polished as Firebase's. The free tier is more limited. And if you're building a mobile-first app with offline support, Firebase's SDK is still better.

But for web-based SaaS products — which is everything I build — Supabase is the clear winner. I haven't looked back since the migration, and I'd make the same choice again in a heartbeat.

Share this post