Backend-as-a-service, two philosophies
Firebase (Google): NoSQL documents, offline sync, push notifications, analytics, a mobile-first universe with generous free tiers. Supabase: real PostgreSQL with instant APIs, auth, storage, row-level security, a SQL universe wearing a managed wrapper. Choosing is choosing your data model, and that choice outlives everything.
Firebase wins when
The product is mobile-first or real-time-collaborative (its sync engine is the industry benchmark), the data model is genuinely document-shaped, push/analytics/remote-config are wanted without assembly, or offline behavior is a requirement. The trap: NoSQL shapes complex relational questions badly, reporting, joins, and "give me all users who did X but not Y" become engineering projects.
Supabase wins when
The data is relational (and most business data is), reporting and ad-hoc queries matter, you want the exit door open (Postgres dumps port anywhere, the lock-in math), or web-first is the shape. The trade: real-time and mobile sync are newer/rougher, and you will think about database indexes like it is 2005, because it is Postgres, and that is the deal.
Lock-in, honestly
Firebase's Gravity is real: data shapes, auth, and analytics knit into Google's API surface; migration out is a rebuild of data access. Supabase's is light: it is Postgres, lift and shift to any host. For products that might outgrow their MVP, that exit door is worth real money; for chat-like mobile apps that live happily on Firebase forever, it is not a factor.
The MVP decision
Mobile app, feeds/chat, offline → Firebase. Web SaaS, relational data, reporting, future-proofing → Supabase. Either ships an MVP in weeks, and both are cheap to START and expensive to choose wrong. The thirty-minute scoping call that prevents that: available directly, or via the brief form.