The pricing verdict from earlier this year still holds, which is itself worth saying out loud after a year where practically every SaaS category covered on this site has restructured its pricing at least once. Supabase and Firebase have both kept their core numbers stable since the original version of this comparison, and the deciding factors between them haven't shifted either. What's changed is smaller and more specific, and worth walking through before repeating the same verdict wholesale.
Pricing, Re-Verified
Supabase's current pricing is unchanged from six months ago: Free at $0/month (500MB database, 1GB storage, 50,000 monthly active users), Pro at $25/month flat (8GB disk, 250GB bandwidth, 100,000 MAU, daily backups with 7-day retention), and Team starting at $599/month (SSO, backup controls, compliance certifications). Compute add-ons scale separately if a project needs more than the included instance size, starting around $10/month for a Micro instance and climbing to $410/month for a 2XL instance, but the base Pro tier price hasn't moved.
Firebase's structure is also unchanged: Spark remains the free tier (1GB Firestore storage, 10GB bandwidth/month, 125K Cloud Function invocations/month), and Blaze remains the pay-as-you-go tier with no flat monthly fee, just usage-based billing across Firestore storage, bandwidth, and function invocations. The specific rates cited in the original comparison, storage around $0.026/GB/month and bandwidth around $0.12/GB, are still current.
That stability across two platforms in a year of aggressive repricing elsewhere is itself informative. It suggests both companies consider their current pricing structurally sound rather than a placeholder waiting for correction, which is a mild point in favor of trusting the numbers you're seeing today will still be roughly accurate next quarter.
What Actually Changed
A few real product updates are worth noting since the original comparison. Supabase shipped Passkeys support for Supabase Auth in beta, adding a modern authentication method beyond password and OAuth flows without requiring a third-party auth provider. Supabase Pipelines entered public alpha, aimed at data movement and ETL-style workflows between Postgres and external systems, a capability that didn't exist in any form when the original comparison was written.
One change worth flagging specifically for anyone on the free tier: as of June 3, 2026, new free-tier Supabase projects using Supabase's default SMTP service can no longer customize auth email templates (the verification, password-reset, and invite emails users see). Existing projects at that point kept their existing customization; new free projects created after that date need to configure a custom SMTP provider to get the same control. It's a minor restriction, but it's exactly the kind of free-tier tightening worth knowing about before assuming the free tier today matches what a six-month-old review described.
Firebase's changes over the same window have been smaller and less publicly documented, consistent with Google's typical pattern of iterating on Firebase without major version-style announcements. The Spark and Blaze tier structure itself, the actual mechanism that decides what a project costs, remains the same shape it's been for years.
The Core Architectural Difference Hasn't Moved
Supabase is PostgreSQL with a managed layer on top: real tables, real SQL, real relational integrity, with auth, storage, realtime, and edge functions built around that same database rather than bolted on as separate proprietary services. Firebase is Firestore, a NoSQL document store, plus a suite of tightly integrated Google Cloud services around it. That's not a detail that shifts with a pricing update; it's the fundamental design decision each platform made at inception, and it still drives the actual choice more than anything else in this comparison.
For a team that wants relational data, joins, and the ability to write ordinary SQL queries against production data, Supabase remains the better fit, unchanged from six months ago. For a mobile-first app with heavy reliance on Google's mobile SDKs, Firebase's maturity there (over a decade of production use across a huge number of iOS and Android apps) still isn't something Supabase has caught up to and likely won't soon, since it's not the platform's focus.
Developer Experience: Still Close, Still Different in Character
Both platforms remain genuinely pleasant to build against, and that hasn't changed. Supabase's auto-generated REST and GraphQL APIs from a Postgres schema mean a working backend exists within minutes of defining tables, and the dashboard's SQL editor lets a developer run real queries directly against production data without leaving the browser. Row Level Security policies, Postgres's native access-control mechanism, give fine-grained permission control that maps naturally onto how a relational schema is already structured.
Firebase's developer experience remains strongest specifically on mobile: the iOS and Android SDKs handle offline sync, real-time listeners, and authentication state in ways that took years of production hardening across an enormous number of shipped apps to get right. A web developer picking up Firebase for the first time faces a steeper conceptual jump, thinking in documents and collections instead of tables and rows, than a web developer picking up Supabase, who can lean on existing SQL knowledge immediately.
Neither platform has meaningfully closed that gap in the past six months. Supabase has not built mobile SDKs approaching Firebase's maturity, and Firebase has not added anything resembling SQL query flexibility. The two platforms remain specialized in opposite directions rather than converging toward each other, which is worth knowing if the expectation was that one would eventually absorb the other's core strength.
Vendor Lock-In: Still the Sharpest Distinction
This was the strongest argument in the original comparison and it remains true today. Supabase's entire stack, Postgres, GoTrue for auth, an S3-compatible storage API, PostgREST for the auto-generated API layer, can be self-hosted via Docker. Leaving Supabase's managed service means exporting a standard Postgres database, not reverse-engineering a proprietary format. Firebase offers no self-hosting path at all; Firestore's document model and Google's proprietary APIs mean migrating away is a genuine rewrite, not an export.
That difference matters more the longer a project runs and the more a team's business depends on the platform underneath it. A six-month-old prototype has low switching risk regardless of platform. A three-year-old production app with real user data has meaningfully different exit costs depending on which of these two a team picked at the start, and that calculus hasn't changed with anything in this refresh.
The Recommendation, Confirmed
The verdict from the original comparison still holds and this refresh didn't surface anything that changes it: choose Supabase for web applications with relational data needs, especially anything built on Next.js or React where Postgres's query flexibility matters. Choose Firebase specifically for mobile-first applications leaning on Google's mobile SDK maturity and broader Google Cloud integration, where Firestore's document model fits the data shape naturally.
The pricing stability on both sides over the past six months is a genuinely useful signal: neither platform is likely to blindside a team with a sudden restructuring in the near term, which is more than can be said for several categories covered elsewhere on this site recently. For teams evaluating the broader self-hosted-versus-managed tradeoff that Supabase's architecture makes possible, the Coolify vs Vercel vs Netlify comparison covers that same self-hosting question for deployment platforms specifically, and the MinIO vs AWS S3 comparison covers it again for object storage, the same underlying pattern showing up across a developer's whole infrastructure stack.