Replacing Firebase with open source: Supabase vs Appwrite vs PocketBase, service by service

A Firebase migration is several migrations. How Supabase, Appwrite and PocketBase handle data, sign-in, files, realtime and access rules, plus a small rehearsal test.

Replacing Firebase is not one decision. An app that uses Firestore, Authentication, Storage and Functions needs a new answer for each of them, and swapping the SDK will not migrate your application.

Here is how the three most common open-source replacements compare, service by service. Everything below links to each project's own documentation, which I reviewed in October 2026.

The short version

• Supabase (Apache-2.0, ~111k GitHub stars): choose it when you want Postgres and SQL underneath, with auth, storage and realtime around it.
• Appwrite (BSD-3-Clause, ~58k stars): choose it when you want backend services behind its APIs rather than assembling them yourself.
• PocketBase (MIT, ~61k stars): choose it for a compact backend that runs as one application with an embedded SQLite database.

Data model

• Supabase: Postgres tables and SQL. You will map Firestore documents, nested collections and references into a relational schema. (docs)
• Appwrite: data behind Appwrite's database APIs. Check which APIs your self-hosted version includes; hosted docs can describe newer features. (docs)
• PocketBase: SQLite-backed collections in one application. Check your queries and relationships against your Firestore model. (docs)

Sign-in

• Supabase: passwords, passwordless sign-in and identity providers. Map account identifiers and reconfigure provider callbacks. (docs)
• Appwrite: email/password, OAuth and passwordless flows. Test the exact methods your app uses on the version you deploy. (docs)
• PocketBase: built-in authentication. Treat account import and existing Firebase sessions as a separate task.

Files

• Supabase: buckets with access policies. Copy file bytes as well as metadata, then test private downloads. (docs)
• Appwrite: file APIs and buckets. Rebuild upload and download calls and file permissions. (docs)
• PocketBase: files attach to records, and protected files use access rules and tokens. Preserve record-to-file relationships when you import. (docs)

Realtime

• Supabase: Broadcast, Presence and Postgres Changes. Replace listeners deliberately and test reconnects. (docs)
• Appwrite: WebSocket subscriptions to resource events that respect permissions. (docs)
• PocketBase: built-in realtime subscriptions. Test the events and reconnect behaviour your app needs.

Access rules

This is where most Firebase migrations go wrong, because security rules do not translate automatically.

• Supabase: Postgres grants and row-level security. Translate each rule and test both allowed and denied requests. (docs)
• Appwrite: permissions name the users and teams that can access each resource. Test with normal client sessions, not only an admin. (docs)
• PocketBase: collection API rules control list, view, create, update and delete. Superusers bypass them, so test with ordinary users. (docs)

Operating it

• Supabase: you run the platform services, database, backups and monitoring, and not every managed-platform feature is part of self-hosting. (docs)
• Appwrite: you operate the deployment and its dependencies. Check release compatibility and backups before cutover. (docs)
• PocketBase: the simplest to run, but its docs warn against production-critical use before v1.0 unless you accept breaking changes and manual migrations.

A one-hour rehearsal before you commit

Run this with fake data in a test environment for each candidate:

1. Create two users, Alice and Bob, and three records owned by Alice, one with a private image. Note the image checksum.
2. Import the records and the image, then run the importer again. You should still have three records, not six.
3. With normal client sessions, confirm Alice can read and edit her records, and that Bob and a signed-out visitor cannot read, edit or download them.
4. Subscribe from a second client, change a record, disconnect and reconnect. Check the client catches up.
5. Restore a backup into a fresh instance and repeat the ownership and file checks.

Whichever backend passes that test with the least rework is your answer. A license does not pay for infrastructure, backups or your team's time, so include those in the cost comparison too.

The full side-by-side comparison, with current license and repository activity for each project, is on PickOpenSource: open-source Firebase alternatives.