Tell us what you're building. We'll come back with a plan.
Why We Pick Supabase Over Firebase for Most New Builds
The Postgres Argument
Every project we ship has a database at its center, and every database decision compounds. Firebase ships a NoSQL document store that feels great for the first month and starts hurting around month three—joins are gymnastics, aggregations get expensive, and any non-trivial reporting requires a second analytical pipeline.
Supabase is just Postgres. That sounds boring until you realize it means every SQL pattern your team already knows works on day one, every BI tool integrates without translation, and migrations are a normal part of life instead of a multi-week project.
Row-Level Security Beats Firebase Rules
Firebase rules are JavaScript-flavored declarative code that runs in a special sandbox. They're fine for simple cases and become a nightmare the moment your auth model has any nuance. We've seen teams spend a week debugging a single rule edge case.
Postgres RLS, by contrast, is just SQL. You write a policy as a predicate, test it with a regular query, and reason about it the same way you reason about every other query in your app. When a client asks "who can see what under condition X," you can answer in five minutes with a SELECT.
Real-Time Without Lock-In
Both platforms offer real-time. Firebase's is more mature for very high fan-out scenarios. Supabase's is built on Postgres logical replication and works beautifully for the use cases we actually ship: collaborative dashboards, live notifications, order status updates.
The critical difference is portability. If we outgrow Supabase's hosted product, we can self-host the entire stack on any Postgres-compatible cloud. If a Firebase project outgrows Firebase, the migration is months of work and a different application architecture.
When Firebase Still Wins
We don't pretend Supabase is universally better. Firebase wins for:
- Pure-mobile apps where Firestore's offline sync is genuinely excellent
- Real-time chat with thousands of concurrent participants per room
- Teams already deeply embedded in the Google Cloud ecosystem
- Products where you need anonymous auth and analytics from day zero
For most of the agency work we do—SaaS dashboards, internal tools, vertical CRMs, AI products—Supabase is the better default.
How We Set It Up On Day One
Every new Supabase project we ship gets the same opinionated baseline within the first two hours:
- Auth configured with email + at least one OAuth provider
- A `profiles` table mirroring `auth.users` for client-readable user data
- RLS policies enabled and audited on every table from the start (never as an afterthought)
- A staging project that mirrors production schema, refreshed weekly
- Migrations versioned in the repo via the Supabase CLI, never edited through the dashboard
This baseline costs us 90 minutes and saves the client weeks of "wait, who can read this table" conversations down the line.
The Honest Tradeoffs
Supabase isn't perfect. The dashboard occasionally lags behind the CLI. Edge functions are still maturing. Pricing at scale is competitive but not always the cheapest. And the realtime layer has hard ceilings that show up around 10,000 concurrent subscribers per channel.
But for the 95% of work we do, the tradeoffs land on the right side of the line. We pick boring, well-understood tools that our clients can hire for, our team can debug at 2 a.m., and that don't lock anyone into a proprietary cage.
Mark P.
🏗️ Writes about infrastructure at LevelByte. Built things at startups and agencies for the last decade.
Tell us what you're building. We'll come back with a plan.
Why We Pick Supabase Over Firebase for Most New Builds
The Postgres Argument
Every project we ship has a database at its center, and every database decision compounds. Firebase ships a NoSQL document store that feels great for the first month and starts hurting around month three—joins are gymnastics, aggregations get expensive, and any non-trivial reporting requires a second analytical pipeline.
Supabase is just Postgres. That sounds boring until you realize it means every SQL pattern your team already knows works on day one, every BI tool integrates without translation, and migrations are a normal part of life instead of a multi-week project.
Row-Level Security Beats Firebase Rules
Firebase rules are JavaScript-flavored declarative code that runs in a special sandbox. They're fine for simple cases and become a nightmare the moment your auth model has any nuance. We've seen teams spend a week debugging a single rule edge case.
Postgres RLS, by contrast, is just SQL. You write a policy as a predicate, test it with a regular query, and reason about it the same way you reason about every other query in your app. When a client asks "who can see what under condition X," you can answer in five minutes with a SELECT.
Real-Time Without Lock-In
Both platforms offer real-time. Firebase's is more mature for very high fan-out scenarios. Supabase's is built on Postgres logical replication and works beautifully for the use cases we actually ship: collaborative dashboards, live notifications, order status updates.
The critical difference is portability. If we outgrow Supabase's hosted product, we can self-host the entire stack on any Postgres-compatible cloud. If a Firebase project outgrows Firebase, the migration is months of work and a different application architecture.
When Firebase Still Wins
We don't pretend Supabase is universally better. Firebase wins for:
- Pure-mobile apps where Firestore's offline sync is genuinely excellent
- Real-time chat with thousands of concurrent participants per room
- Teams already deeply embedded in the Google Cloud ecosystem
- Products where you need anonymous auth and analytics from day zero
For most of the agency work we do—SaaS dashboards, internal tools, vertical CRMs, AI products—Supabase is the better default.
How We Set It Up On Day One
Every new Supabase project we ship gets the same opinionated baseline within the first two hours:
- Auth configured with email + at least one OAuth provider
- A `profiles` table mirroring `auth.users` for client-readable user data
- RLS policies enabled and audited on every table from the start (never as an afterthought)
- A staging project that mirrors production schema, refreshed weekly
- Migrations versioned in the repo via the Supabase CLI, never edited through the dashboard
This baseline costs us 90 minutes and saves the client weeks of "wait, who can read this table" conversations down the line.
The Honest Tradeoffs
Supabase isn't perfect. The dashboard occasionally lags behind the CLI. Edge functions are still maturing. Pricing at scale is competitive but not always the cheapest. And the realtime layer has hard ceilings that show up around 10,000 concurrent subscribers per channel.
But for the 95% of work we do, the tradeoffs land on the right side of the line. We pick boring, well-understood tools that our clients can hire for, our team can debug at 2 a.m., and that don't lock anyone into a proprietary cage.
Mark P.
🏗️ Writes about infrastructure at LevelByte. Built things at startups and agencies for the last decade.
Why We Pick Supabase Over Firebase for Most New Builds
The Postgres Argument
Every project we ship has a database at its center, and every database decision compounds. Firebase ships a NoSQL document store that feels great for the first month and starts hurting around month three—joins are gymnastics, aggregations get expensive, and any non-trivial reporting requires a second analytical pipeline.
Supabase is just Postgres. That sounds boring until you realize it means every SQL pattern your team already knows works on day one, every BI tool integrates without translation, and migrations are a normal part of life instead of a multi-week project.
Row-Level Security Beats Firebase Rules
Firebase rules are JavaScript-flavored declarative code that runs in a special sandbox. They're fine for simple cases and become a nightmare the moment your auth model has any nuance. We've seen teams spend a week debugging a single rule edge case.
Postgres RLS, by contrast, is just SQL. You write a policy as a predicate, test it with a regular query, and reason about it the same way you reason about every other query in your app. When a client asks "who can see what under condition X," you can answer in five minutes with a SELECT.
Real-Time Without Lock-In
Both platforms offer real-time. Firebase's is more mature for very high fan-out scenarios. Supabase's is built on Postgres logical replication and works beautifully for the use cases we actually ship: collaborative dashboards, live notifications, order status updates.
The critical difference is portability. If we outgrow Supabase's hosted product, we can self-host the entire stack on any Postgres-compatible cloud. If a Firebase project outgrows Firebase, the migration is months of work and a different application architecture.
When Firebase Still Wins
We don't pretend Supabase is universally better. Firebase wins for:
- Pure-mobile apps where Firestore's offline sync is genuinely excellent
- Real-time chat with thousands of concurrent participants per room
- Teams already deeply embedded in the Google Cloud ecosystem
- Products where you need anonymous auth and analytics from day zero
For most of the agency work we do—SaaS dashboards, internal tools, vertical CRMs, AI products—Supabase is the better default.
How We Set It Up On Day One
Every new Supabase project we ship gets the same opinionated baseline within the first two hours:
- Auth configured with email + at least one OAuth provider
- A `profiles` table mirroring `auth.users` for client-readable user data
- RLS policies enabled and audited on every table from the start (never as an afterthought)
- A staging project that mirrors production schema, refreshed weekly
- Migrations versioned in the repo via the Supabase CLI, never edited through the dashboard
This baseline costs us 90 minutes and saves the client weeks of "wait, who can read this table" conversations down the line.
The Honest Tradeoffs
Supabase isn't perfect. The dashboard occasionally lags behind the CLI. Edge functions are still maturing. Pricing at scale is competitive but not always the cheapest. And the realtime layer has hard ceilings that show up around 10,000 concurrent subscribers per channel.
But for the 95% of work we do, the tradeoffs land on the right side of the line. We pick boring, well-understood tools that our clients can hire for, our team can debug at 2 a.m., and that don't lock anyone into a proprietary cage.
Mark P.
🏗️ Writes about infrastructure at LevelByte. Built things at startups and agencies for the last decade.
Tell us what you're building. We'll come back with a plan.
Why We Pick Supabase Over Firebase for Most New Builds
The Postgres Argument
Every project we ship has a database at its center, and every database decision compounds. Firebase ships a NoSQL document store that feels great for the first month and starts hurting around month three—joins are gymnastics, aggregations get expensive, and any non-trivial reporting requires a second analytical pipeline.
Supabase is just Postgres. That sounds boring until you realize it means every SQL pattern your team already knows works on day one, every BI tool integrates without translation, and migrations are a normal part of life instead of a multi-week project.
Row-Level Security Beats Firebase Rules
Firebase rules are JavaScript-flavored declarative code that runs in a special sandbox. They're fine for simple cases and become a nightmare the moment your auth model has any nuance. We've seen teams spend a week debugging a single rule edge case.
Postgres RLS, by contrast, is just SQL. You write a policy as a predicate, test it with a regular query, and reason about it the same way you reason about every other query in your app. When a client asks "who can see what under condition X," you can answer in five minutes with a SELECT.
Real-Time Without Lock-In
Both platforms offer real-time. Firebase's is more mature for very high fan-out scenarios. Supabase's is built on Postgres logical replication and works beautifully for the use cases we actually ship: collaborative dashboards, live notifications, order status updates.
The critical difference is portability. If we outgrow Supabase's hosted product, we can self-host the entire stack on any Postgres-compatible cloud. If a Firebase project outgrows Firebase, the migration is months of work and a different application architecture.
When Firebase Still Wins
We don't pretend Supabase is universally better. Firebase wins for:
- Pure-mobile apps where Firestore's offline sync is genuinely excellent
- Real-time chat with thousands of concurrent participants per room
- Teams already deeply embedded in the Google Cloud ecosystem
- Products where you need anonymous auth and analytics from day zero
For most of the agency work we do—SaaS dashboards, internal tools, vertical CRMs, AI products—Supabase is the better default.
How We Set It Up On Day One
Every new Supabase project we ship gets the same opinionated baseline within the first two hours:
- Auth configured with email + at least one OAuth provider
- A `profiles` table mirroring `auth.users` for client-readable user data
- RLS policies enabled and audited on every table from the start (never as an afterthought)
- A staging project that mirrors production schema, refreshed weekly
- Migrations versioned in the repo via the Supabase CLI, never edited through the dashboard
This baseline costs us 90 minutes and saves the client weeks of "wait, who can read this table" conversations down the line.
The Honest Tradeoffs
Supabase isn't perfect. The dashboard occasionally lags behind the CLI. Edge functions are still maturing. Pricing at scale is competitive but not always the cheapest. And the realtime layer has hard ceilings that show up around 10,000 concurrent subscribers per channel.
But for the 95% of work we do, the tradeoffs land on the right side of the line. We pick boring, well-understood tools that our clients can hire for, our team can debug at 2 a.m., and that don't lock anyone into a proprietary cage.
Mark P.
🏗️ Writes about infrastructure at LevelByte. Built things at startups and agencies for the last decade.
Tell us what you're building. We'll come back with a plan.
