Compares Firebase's NoSQL Firestore and Google-hosted services with self-hosted Supabase's Postgres, PostgREST, Auth, Storage, Realtime and Edge Functions: the data model change from documents to tables, client SDK rewrites, security rules versus Postgres row level security, and what the team must operate.
Compares Firebase with self-hosted Appwrite, whose auth, databases, storage, functions, messaging and realtime map closely to Firebase's product set: Appwrite 2.0's PostgreSQL default and optional document database, SDK coverage, Helm or Docker operations, and Appwrite's built-in Firebase migration.
For smaller apps only: Firebase against PocketBase's single Go executable with embedded SQLite, realtime subscriptions and auth, covering its vertical-only scaling, pre-1.0 compatibility warning, volunteer maintenance and the absence of a documented Firebase importer.
Supabase's documented Firebase path: exporting Firestore collections to JSON and loading them into Postgres tables, importing Auth users into auth.users with the project's scrypt parameters, moving Storage files, and the password and data-model gaps to test before cutover.
Appwrite's built-in Firebase migration: the service account roles it needs, what moves (users, Firestore data, files) and what does not (Realtime Database, nested data, OAuth sessions, Cloud Functions), and the platform and permission setup after import.
Firebase's usage-based Blaze bills (Firestore reads and writes, Auth MAUs, Storage, Functions, Hosting transfer) against self-hosted Supabase, Appwrite or PocketBase: servers, storage, backups, the one-time migration and rewrite, and the people who operate and patch the stack.
Getting data out of Firebase service by service: Firestore managed exports to Cloud Storage, Auth user exports with password hashes and scrypt parameters, Realtime Database JSON backups, plus the costs, permissions and gaps each export has.
Why Firebase cannot keep all app data in the EU, since Firebase Authentication processes data only in the United States even when Firestore uses the eur3 location, and how self-hosted Supabase or Appwrite in an EU data center keeps auth, data and files together.
Replacing Firestore's document database and per-operation billing: Supabase's Postgres tables with PostgREST, Appwrite's databases, or PocketBase's embedded SQLite, and how collections, subcollections, security rules and listeners map onto each.
Replacing Firebase Authentication, which runs only from US data centers, with Supabase Auth, Appwrite's auth or ZITADEL: moving users with their modified scrypt password hashes, re-linking social providers, and SAML or OIDC for enterprise sign-in.
Moving server code off Cloud Functions, which needs the Blaze plan: Supabase Edge Functions on the Deno-based Edge Runtime, Appwrite Functions on Open Runtimes, or PocketBase's JavaScript hooks, and how triggers on database and auth events translate.
Replacing the Firebase Realtime Database and its connection limits with Supabase Realtime over Postgres, Appwrite Realtime or PocketBase realtime subscriptions, including data model changes from a JSON tree and scaling persistent connections.
Since Cloud Storage for Firebase requires the Blaze plan, some teams move files out: Supabase Storage, Appwrite Storage or PocketBase file fields, backed by local disk or S3-compatible storage such as Garage or SeaweedFS, with access rules rebuilt.
Moving static sites and web apps from Firebase Hosting to Coolify or Dokploy on your own servers, or to the static hosting in Appwrite Sites, including redirects, rewrites to functions, custom domains and TLS.
Firebase Extensions shuts down on March 31, 2027, after which deployed extensions can no longer be updated, reconfigured or uninstalled. This page covers inventorying extensions, rebuilding them as functions, and using the deadline to plan a wider move.