Supabase + Flutter

The frontend is the same Flutter app; the backend philosophy is the opposite. Firebase's Firestore is a document database: schemaless, with real-time sync built in, but no joins and no SQL, and costs that scale with document reads. Supabase is PostgreSQL: full relational queries, joins, and foreign keys, row-level security policies that run inside the database, and pricing that scales on database size and traffic rather than per-read. Supabase is also open source, so the same stack can be self-hosted or moved to another Postgres host later; Firebase is Google's managed platform. Choose Supabase when the data model is relational or portability matters; choose Firebase when offline-first document sync is the core feature.

The free plan carries 50,000 monthly active users on auth, 500 MB of database space, and 1 GB of file storage, and pauses projects after a week of inactivity, which makes it fine for development and small pilots. The walls arrive in a predictable order: file storage first for apps with uploads, database size next for anything that logs events, then auth users for consumer apps with real traffic. The Pro plan at $25 a month lifts all of those (8 GB database, 100,000 monthly active users, 100 GB storage) and adds daily backups; beyond Pro, the numbers that grow are compute size and egress, both billed per unit. For most apps the honest jump is $0 to $25, and it arrives around launch rather than years later.

Yes, and this is the stack's main strategic advantage over Firebase. Supabase is open source (PostgreSQL plus its own auth, storage, and realtime layers), and the platform publishes a self-hosting setup you can run with Docker on any server, so the managed service is a convenience rather than a dependency. The data itself is a plain PostgreSQL database: pg_dump produces a standard dump any Postgres host accepts, and the Flutter app talks to Supabase through its generated APIs, so switching to self-hosted is mostly repointing the project at a new URL. The honest caveat is operational: the managed service handles backups, updates, and realtime infrastructure, and taking those on yourself is real work. The escape route exists; whether to use it is a trade-off, not a lock-in.

Yes, on any table the Flutter app can touch. The supabase_flutter SDK reaches the database through Supabase's auto-generated REST API using an anon key that ships inside the app, so without a policy a table is readable by anyone holding that key, which is anyone who extracts it from the app. A row-level security policy is what turns that open door into per-user access, checked inside PostgreSQL against the authenticated user. The classic mistake is developing with the service key, which bypasses RLS and makes everything work, then shipping the app with the anon key and watching queries return empty rows. Enable RLS first, write policies against auth.uid(), and develop with the anon key from the start.

Only for the purchases Apple and Google allow outside their own systems. Stripe's flutter_stripe SDK handles physical goods, services fulfilled outside the app (a booking, a delivery, a course consumed on the web), and subscriptions to real-world services; Apple's and Google's rules require digital goods consumed inside the app itself (premium features, digital content, in-app currency) to go through StoreKit on iOS and Google Play Billing on Android, with their 15 to 30 percent cut. The practical split used by most apps: Stripe for anything with a real-world component, the platform's in-app purchase system for digital unlocks. Subscriptions are the edge case to check carefully, since the rules differ between platforms and both companies enforce them at review time.