Firebase vs Supabase: When I Would Choose Each One

A few years ago, this decision would have looked very different. If you wanted to build a serious mobile application, you would often need a backend engineer fairly early in the process. Authentication, databases, file storage, notifications, infrastructure, monitoring, and deployment all required significant effort before you could even start thinking about the actual product.

Today, that's no longer necessarily the case.

Over the past few years, I've worked on production applications built on Firebase and more recently started building a new project using Supabase. Spending time with both platforms has taught me something interesting: most comparisons focus on the wrong question.

After working with both, I've come to believe that the discussion isn't really about which platform is objectively better. The more useful question is which platform is a better fit for the product you're trying to build.

The Biggest Change Isn't Firebase or Supabase

What stands out to me most isn't Firebase or Supabase themselves. It's how dramatically the development landscape has changed.

When I worked on a wellness application built on Firebase, the platform allowed me to move incredibly fast. Authentication, storage, push notifications, analytics, and a database were available almost immediately. As a mobile developer, I was able to spend most of my time thinking about the product and user experience rather than infrastructure.

That doesn't mean backend work disappeared. Security rules still needed careful design. Data models still mattered. Authentication flows still required thoughtful implementation. As the product evolved, cloud functions and backend logic naturally became part of the architecture.

The difference was that I could reach a functional, production-ready application much faster than would have been possible a few years earlier.

Today, platforms like Firebase and Supabase allow individual developers and small teams to build products that previously would have required multiple specialized roles. In my opinion, that's the most important change happening here.

What Firebase Gave Me

What Firebase gave me more than anything else was speed.

For mobile-first applications, the experience is difficult to beat. Authentication is straightforward, push notifications are deeply integrated, storage is simple to configure, and analytics can be enabled with very little effort. The entire platform feels optimized around helping teams ship products quickly.

In the wellness application I worked on, that speed was incredibly valuable. There were features to validate, users to support, bugs to fix, and product decisions to make. The less time spent managing infrastructure, the more time we could spend improving the actual product.

As the application grew, some of those trade-offs became concrete in ways that were worth understanding.

One example came when we built the social feed. Firestore's in operator has a hard limit of thirty elements per query. That worked fine early on, but once users started following more than thirty accounts, the feed stopped showing everyone's posts. The fix required splitting queries into chunks and merging results client-side. It wasn't complicated, but it was something we hadn't planned for, and it only became visible once real users were actually following each other.

A second moment came with follower counts. We were using FieldValue.increment and FieldValue.decrement to track followers and following numbers, which is the standard Firestore approach. Over time, with concurrent operations and edge cases like blocking a user who only had a pending follow request, the counts started drifting. Some users ended up with negative follower counts. We eventually switched to real-time COUNT aggregation, which self-corrects, but it took a production issue to surface the problem.

Neither of these was a reason to avoid Firebase. Both had straightforward solutions. But they're honest illustrations of what "Firestore data modeling requires planning" actually means in practice. It's not abstract. It shows up in specific decisions around query design, concurrency handling, and how you model relationships between users and data.

None of these challenges are unique to Firebase, nor are they necessarily weaknesses. They're simply the trade-offs that come with a platform optimized for a particular set of priorities.

What Supabase Feels Like

Building on Supabase has felt different from day one. Not necessarily better or worse, just optimized around a different set of assumptions.

The first thing I noticed was how natural the data modeling process felt. In the property management application I'm currently building, entities such as properties, tenants, maintenance requests, providers, expenses, and documents all have relationships with one another. Modeling those relationships directly in PostgreSQL felt intuitive.

I wasn't thinking about how to structure documents or work around query limitations. I was thinking about the business domain and how the data naturally related to itself.

That distinction may sound subtle, but it influences many architectural decisions.

Views, joins, foreign keys, policies, triggers, and SQL become normal parts of the development process. While Supabase still provides many of the conveniences developers expect from modern backend platforms, it feels closer to working with a traditional backend system that happens to remove a significant amount of operational overhead.

For applications with rich relationships between entities, that can be a very comfortable place to be.

One pattern I've noticed repeatedly is that I spend less time adapting the data model to fit the platform and more time focusing on the problem I'm trying to solve.

As the application grew, some of that became concrete in ways worth understanding.

One example came when implementing soft delete. The operation failed with a generic error. Looking at the Postgres logs, the issue was that the SELECT policy had deleted_at IS NULL as a filter. When an UPDATE sets deleted_at, Postgres validates the resulting row against the SELECT policy — not just the UPDATE policy. The row no longer passes the read filter, so the write is rejected. The fix was to scope SELECT policies by ownership only and filter deleted_at in the query layer. Not complicated, but genuinely surprising the first time.

A second moment came when building the property journal — a chronological feed aggregating six entity types: maintenance records, leases, tenants, documents, and photos. In a document-oriented system, that likely means a separate events table or merging multiple queries client-side. In Postgres, it became a single read-only view: a UNION ALL with row-level security. Sorted, searchable, and paginated from one place, with nothing to maintain.

Neither of these was a reason to avoid Supabase. Both had clean solutions. But they are honest illustrations of what "SQL becomes a normal part of the development process" looks like in practice — it shows up in how policies interact with writes, and in the specific patterns you reach for when an answer is not immediately obvious.

A Few Lessons I'd Carry Forward

After working with both platforms, I've realized that some lessons matter far more than the actual technology choice.

Security First, Not Later

Whether you're using Firebase Security Rules or Supabase RLS, security quickly becomes part of your architecture. The earlier you think about permissions and access control, the easier the system tends to be to maintain as it grows.

Design Data Around the Business Domain

One thing both projects reinforced is that the data model matters more than the database technology itself.

I've found it useful to spend time understanding how information relates to itself before creating collections, tables, or APIs. Good data models tend to survive technology changes surprisingly well.

Keep Sensitive Logic Off the Client

Modern platforms make it incredibly easy to build large portions of an application directly from the mobile app.

That's powerful, but I've become increasingly careful about where business rules live. Permissions, quotas, subscription checks, and other sensitive operations tend to age better when they're enforced on the backend rather than trusted to the client.

Final Thoughts

After building products on both platforms, I've stopped thinking about Firebase and Supabase as direct competitors.

Firebase helped me move extremely fast and focus on product development. Supabase gives me greater flexibility in how data is modeled and queried. Both are capable of supporting serious applications, and both solve real problems exceptionally well.

What ultimately drove my decision wasn't the platform itself. It was the type of application I was building.

A wellness application and a property management platform have very different requirements, and those differences naturally pushed me toward different solutions.

The bigger lesson, however, has very little to do with Firebase or Supabase.

A few years ago, the question was:

"Do we have a backend team?"

Today, it's often:

"How far can we get before we need one?"