Which self-hosted alternatives to Firebase are available?

Supabase and Appwrite are the main options here. PocketBase complements the comparison for bounded requirements; its documentation warns against production-critical use without willingness to perform manual migrations. Required services and operational responsibility determine the choice.

Is Supabase a compatible replacement for Firestore?

No. Firestore stores documents and collections. Supabase uses PostgreSQL. The data model, queries and permissions must match the destination; an export does not replace that work.

Can I self-host Firebase using the Emulator Suite?

No. Firebase documentation explicitly rules out using the emulators as self-hosted Firebase services in production. They are development and testing tools.

Is self-hosting automatically GDPR compliant?

No. Processing arrangements, technical and organisational measures and, where applicable, third-country transfers must be assessed for the specific deployment. A server location alone does not meet these requirements.

Does a Firestore export include authentication and files?

No. Supabase documents separate migration paths for Firestore data, Firebase Auth and Firebase Storage. The project must accept these datasets together with their relationships.

Can existing Firebase passwords simply remain unchanged?

There is no blanket guarantee. The Supabase guide covers exporting and importing auth users and Firebase hash parameters. It refers to a middleware solution for verifying existing passwords and updating them on first login.

Is self-hosted Supabase identical to Supabase Cloud?

No. The self-hosting documentation lists differences, including managed backups, PITR and branching. Backup, monitoring and updates need a separate operational plan when you run the platform yourself.

What does WZ-IT offer for leaving Firebase?

WZ-IT offers assessment and implementation of migration to Supabase. Appwrite hosting, installation and operations form a separate offer path. Technical transferability and the respective scope are established beforehand.

Firebase Alternatives: Supabase, Appwrite and Self-Hosting

Timo Wevelsiep29.10.2026

#Firebase
#Supabase
#Appwrite
#SelfHosting

Editorial note: The information in this article was compiled to the best of our knowledge at the time of publication. Technical details, prices, versions, licensing terms, and external content may change. Please verify the information provided independently, particularly before making business-critical or security-related decisions. This article does not replace individual professional, legal, or tax advice.

Assess leaving Firebase: Review Supabase migration covering data, auth and the application or Appwrite hosting and operations. Arrange a consultation.

A Firebase alternative should be selected against the services actually used. This comparison covers Supabase, Appwrite and, additionally, PocketBase for a backend you take responsibility for operating. The selection is a technical decision aid, not a ranking based on performance tests. As of October 2026.

The short answer: Supabase is a candidate when PostgreSQL is the intended target model. Appwrite is a candidate for a backend with integrated APIs for auth, data, files and functions. PocketBase requires a separate assessment of its operational limitations. The properties and limitations are linked to primary sources below.

Inventory the Firebase services actually used
Compare Supabase, Appwrite and PocketBase
Supabase vs Firebase also concerns the data model
Transfer authentication and storage separately
Assess GDPR requirements for the actual deployment
Cost self-hosting and operations together
Plan migration around acceptance criteria
Our approach at WZ-IT
Further guides

Inventory the Firebase services actually used

Firebase is not a single database type for selection purposes. Even within one project, Firestore, Realtime Database, Storage and Functions resources can have different locations. Inventory the actual deployment per service. Firebase location model.

Our recommendation: create a service inventory before comparing products. Mark each function for retention, replacement or removal. Document dependencies outside the backend instead of counting only stored data.

Inventory	Resolve for target selection
Data and queries	Collections, relationships, write paths and required searches
User access	Login methods, roles, tenants and account recovery
Files	References, access rights, retention and downloads
Background logic	Events, schedules, external APIs and retries
Application	SDK calls, offline behaviour and error cases
Operations	Owners for changes, backup and recovery

A common misconception: Firebase Local Emulator Suite is not a production self-hosting option. Its documentation explicitly excludes this use because the emulators are designed for testing. Emulator limitations.

Compare Supabase, Appwrite and PocketBase

The table classifies documented properties. The last column is our assessment question, not a product or WZ-IT performance promise.

Candidate	Documented foundation	Our assessment question
Supabase	Self-hosting is documented; Firestore migration targets PostgreSQL. Self-hosting, migration model	Is a relational target model intended?
Appwrite	APIs for Auth, Databases, Storage, Functions and Realtime; self-hosting is supported. Feature overview, self-hosting	Do APIs, permissions and application integration fit the estate?
PocketBase	Embedded SQLite, authentication, realtime subscriptions and an API; documentation warns about production-critical applications. Introduction	Is the use case bounded, and can manual migration steps be managed?

At the stated date, PocketBase does not guarantee full backward compatibility before version 1.0. The project's warning makes a blanket recommendation for production-critical backends inappropriate. PocketBase limitation. Its inclusion provides context; no additional WZ-IT offer is implied.

Our selection rule: assess Supabase first for a desired PostgreSQL destination and Appwrite for an API-based backend design. Reject a candidate if a required function or a manageable implementation remains unresolved. A longer feature list does not replace acceptance of your own application.

Supabase vs Firebase also concerns the data model

Cloud Firestore organises documents into collections and supports nested objects and subcollections. This differs from relational tables. Firestore data model.

The documented Supabase migration path initially maps one collection to one PostgreSQL table. More complex structures can be split into related tables before import. This does not provide automatic business-level modelling. Firestore migration tools.

We recommend defining business keys and relationships before import. Decide which nested values should remain JSON and which need their own table. Then assess representative queries and changes, including deletion cases. Matching record counts is only one control point.

Access control also needs its own design: Supabase combines database grants and PostgreSQL Row Level Security. Existing Firebase rules should therefore be assessed against their business meaning. Supabase RLS. For acceptance, we recommend positive and negative tests per role and tenant: an allowed query must succeed, and access to another tenant's data must fail.

Transfer authentication and storage separately

Firebase Auth and Firebase Storage have separate migration guides. A successful Firestore import therefore does not establish a complete backend migration. Auth migration, storage migration.

For auth, Supabase documents user export, import and saving Firebase hash parameters. For verifying existing passwords and updating them at first login, the guide refers to a middleware path. This must not become a blanket promise that all logins continue unchanged. Auth procedure.

Our checklist consequently separates identity, login, authorisation and files. Map old and new IDs traceably; assess account recovery and selected provider logins. For files, we additionally recommend checking references, metadata and access from the application. Functions and external integrations need their own acceptance points.

Searching for a “Firebase alternative GDPR” cannot be answered by a product name. GDPR Article 28 addresses processor requirements, Article 32 security of processing, and Chapter V transfers to third countries. These assessments concern actual data flows and the parties involved. GDPR primary text.

Our recommendation is a data-flow inventory covering production data, backups, logs, email delivery, identity providers and support access. Document responsibilities and contracts. A self-operated server in Germany does not replace this assessment, nor does choosing a European cloud region. The legal assessment of the specific deployment belongs with the responsible privacy and legal specialists.

Cost self-hosting and operations together

Self-hosted Supabase places maintenance, security updates, backup, recovery and monitoring among the operator's responsibilities. Some managed-platform features are also unavailable, including managed backups, PITR and branching. Supabase operational boundaries. Appwrite likewise documents self-hosting tasks for security, backups and updates. Appwrite operations.

Our comparison therefore includes more than server rental:

Infrastructure including storage, data transfer and reserve capacity.
Platform maintenance, monitoring and incident handling.
Backup and verifiable recovery.
External communication and identity services.
One-off application changes, data transfer and transition operations.

Compare the same functional scope and assessment period. This article treats self-hosting as neither free nor automatically cheaper. If required functions or operational responsibility remain unresolved, we recommend also assessing remaining with Firebase.

Plan migration around acceptance criteria

The following process is our planning recommendation:

Define the estate and target candidate, including remaining external services.
Assess the data model, identities and permissions using representative data.
Accept application paths including uploads, login and background processing.
Define the authoritative dataset, write freeze and final reconciliation.
Document switching criteria, backup and recovery.
Define a return path for cases where new data already exists at the destination.
Decommission the source only after business acceptance and clarified retention.

A return path needs more than resetting an endpoint: establish how new destination changes are handled and which environment may write. The existing Firebase-to-Supabase guide develops the technical migration path; this comparison supports the preceding target selection.

Our approach at WZ-IT

Supabase migration considers data, auth, storage, functions and the application together. Which Firebase components can be transferred or adapted is technically assessed. Installation, hosting and operations are available for an Appwrite destination; this does not imply an unassessed commitment to a complete Firebase-to-Appwrite migration.

Useful enquiry information includes Firebase services in use, login methods, data structures, external integrations and requirements for target operations. Migration and ongoing operations are scoped appropriately.