Flutter + Firebase

Both stacks use Flutter for the frontend, but the backends are fundamentally different. Firebase uses Firestore, a document database with real-time listeners and no SQL; Supabase wraps PostgreSQL, giving you full relational queries, joins, and the option to self-host. Firebase's real-time sync is built into the database layer and works out of the box; Supabase achieves the same effect through PostgreSQL's realtime subscriptions, which require a bit more configuration. Firebase locks you into Google's managed platform; Supabase lets you export your data as a standard PostgreSQL dump and move to any Postgres host. If the app's data model is naturally relational (users with orders with line items), Supabase fits better. If real-time document sync is the core feature and Google's managed platform is acceptable, Firebase wins.

Firebase's Spark plan includes 50,000 document reads per day for free, which covers prototyping and early-stage apps comfortably. Once the app has active daily users, reads scale quickly: a list view that loads 50 documents per screen, with a user opening 10 screens per session, generates 500 reads per user per session. At 1,000 daily active users, that is 500,000 reads per day, or roughly $9 per month on the Blaze plan. The cost compounds with real-time listeners that re-read documents on every change. Optimizing read patterns (caching, composite documents, pagination with cursors) is the main lever for keeping Firebase costs under control at scale.

Firestore does not support joins, OR conditions across different fields, inequality filters on multiple fields, or arbitrary aggregation queries. When the app needs relational-style queries (for example, "find all orders from users in this city placed in the last week"), the standard approach is to denormalize the data: embed the user's city into each order document so a single-field query works. For queries that denormalization cannot solve, Cloud Functions can run server-side aggregations and write the results back to Firestore as pre-computed documents. This is the main architectural trade-off of choosing Firestore over a SQL database: query simplicity is exchanged for real-time sync and horizontal scaling.

Partially. Firebase Auth users can be exported as a JSON file with password hashes and profile data, so user accounts are portable in principle, but the authentication flow must be rebuilt against a new provider (Supabase Auth, Auth0, or a custom solution). Firestore data exports to JSON or CSV, but the document structure rarely maps cleanly to a relational schema, so migrating to PostgreSQL means reshaping the data model, not just dumping and importing. The Flutter UI and business logic are portable since they do not depend on Firebase directly, but every Firestore query, Firebase Auth call, and Cloud Function must be replaced. The migration is feasible but substantial, which is the main reason to evaluate the lock-in trade-off before committing.

Firebase ships with Google Analytics for Firebase at no extra cost, and it covers the standard mobile engagement questions: daily active users, retention cohorts, screen views, and custom events. For most mobile apps, this is sufficient. PostHog adds capabilities that Google Analytics does not offer: session replays (seeing exactly what a user tapped and scrolled through), feature flags for gradual rollouts, and A/B testing tied to product events rather than marketing campaigns. If the app needs product experimentation or detailed user behavior debugging, PostHog earns its place alongside the built-in analytics. If the questions are limited to "how many users" and "which screens," Firebase Analytics alone is enough.