Which backend fits: Firebase or self-hosted Appwrite
Firebase fits teams that want Google to run the backend, already use Firestore or other Google services, and have no requirement to keep auth, data and files in infrastructure they control. Self-hosted Appwrite fits teams that need the backend inside their own cloud account, data center or private network, that want a BSD-3-Clause codebase they can inspect and modify, and that have people able to operate Docker Compose or Kubernetes. If your renewal, Blaze billing or data residency concern is the trigger, the question is less about feature parity than about who will run the stack after cutover.
Appwrite covers the same product areas most Firebase apps use: Auth, Databases, Storage, Functions, Messaging and Realtime. Its Firebase migration imports users, Firestore data and files, but Realtime Database content, nested data, OAuth sessions and Cloud Functions do not move automatically, so inventory those before you commit. Check the server SDK and client SDK coverage against your stack, and confirm which database engine you need, since Appwrite 2.0 provisions PostgreSQL by default and DocumentsDB and VectorsDB ship disabled. The single-replica default for built-in datastores in the Helm chart means your team must plan for managed PostgreSQL, Redis, ClickHouse and object storage, or for operators, before the system holds production data.
The decision turns on four points. First, data location: Firebase Authentication processes data only in the United States, so confirm whether that is acceptable and where your self-hosted nodes would sit. Second, operating capacity: count who will patch, back up, upgrade and monitor the stack, and who answers when it fails, because self-hosted Appwrite has no vendor-run failover. Third, the Firebase features you use, especially Realtime Database, extensions and Cloud Functions triggers, since each needs a rebuilt equivalent. Fourth, tolerance for self-managed availability. If the answer to the first three is an in-region data requirement, a team that can run containers and a plan for replicated data services, self-hosted Appwrite is worth a scoped proof of concept against your own data.
Which option fits each scenario
This table matches common Firebase replacement scenarios to the option that usually fits better, with the condition that drives the choice. Read each row against your own data residency rules, team capacity and the Firebase features your app depends on, because the right answer changes when those conditions change.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Firebase Auth users with US-only processing is a problem | Self-hosted Appwrite | Appwrite runs in the infrastructure you choose, so user records and sessions stay where you deploy them. Confirm the hosting region of your own cluster or cloud account. |
| EU or private data residency | Self-hosted Appwrite in an EU data center | Firebase Authentication processes data only in the United States, so auth cannot be kept in the EU on Firebase. Self-hosting lets auth, databases and files share one location you control. |
| Small team with no operations capacity | Appwrite Cloud or a managed Firebase setup | Self-hosting makes your team responsible for upgrades, patching, backups and monitoring. Appwrite's self-hosted Helm docs state built-in datastores run a single replica without failover, so an unmanaged install is not a substitute for managed availability. |
| Apps depending on Firebase Realtime Database or Cloud Functions | Review before choosing Appwrite | Appwrite's migration does not move the Realtime Database or Cloud Functions, so these need to be rebuilt on Appwrite Realtime and Appwrite Functions. Estimate rewrite effort with a written scope before committing. |
| Teams already on Firestore wanting a document model | Appwrite databases with DocumentsDB or a document engine | Appwrite 2.0 provisions PostgreSQL by default, and DocumentsDB for schemaless JSON needs PostgreSQL and MongoDB engines that a stock install does not deploy. Confirm the engine setup before committing to a document model. |
| Regulated workloads needing self-run backups | Self-hosted Appwrite with your own backup tooling | Backup, restore and point-in-time recovery are your responsibility when self-hosting, and the built-in datastores need external managed services or operators for production durability. Confirm the backup, restore and retention evidence an assessor will expect. |
| Firebase Auth users with password hashes to preserve | Self-hosted Appwrite | Appwrite's Users API accepts imported Scrypt modified hashes, so users can often sign in without a forced password reset. Test the import with a sample export before cutover. |
Where data lives and who controls it
Data residency is the first constraint to check, and on Firebase it is partly fixed before any code is written. Firebase Authentication processes data only in the United States, so a team that chooses a European Cloud Firestore location still has user accounts, sign-in events and identifiers processed in the US. Cloud Firestore's location cannot be changed after the database is provisioned, which means a wrong choice at setup becomes a migration project later. Before comparing products, ask your legal and privacy teams which data categories must stay in a given jurisdiction, then check Firebase's current position in the Firebase privacy and security documentation and the Cloud Firestore locations guide.
Self-hosted Appwrite changes the question from which vendor region you select to which infrastructure you control. You deploy the stack with Docker Compose or the Helm chart into your own cloud account, a data center or an air-gapped network, so the auth tables, databases, storage buckets and function runtimes sit in one place you choose. That keeps identity and application data together, which is the property Firebase cannot offer for authentication. Appwrite Cloud is also available as a hosted edition, and its region options are a separate decision: confirm in the Appwrite Cloud console and with Appwrite which regions are offered for your plan, where backups are stored and which sub-processors handle data before you treat it as equivalent to self-hosting.
Self-hosting moves responsibility rather than removing it. Your team owns the encryption keys for disks, object storage and database backups, the access model for operators, log retention and the network boundaries around the stack. Residency is a property you must document, and compliance evidence must be gathered from your own systems. DeployOpen can prepare configurations, controls and evidence for an assessment, but independent auditors and certification bodies issue any report or attestation. Before a migration, ask for a written data flow diagram that lists every component holding personal data, and confirm each one against your residency requirements.
Hosting models: managed Firebase, Appwrite Cloud or self-hosted Appwrite
Firebase runs as a fully managed service on Google infrastructure. Google operates the databases, authentication, storage, and functions, so your team does not patch servers, size clusters, or plan failover for those services. The trade-off is that the platform, its pricing model, and its data locations are set by Google, and several decisions are fixed after provisioning.
- Operations: Google handles scaling and infrastructure. Your team manages security rules, deployments, and application code.
- Data location: A Cloud Firestore database's location cannot be changed after it is created, and Firebase Authentication processes data only in the United States.
- Cost model: Usage is billed by consumption, and several services, including Cloud Storage for Firebase, require the pay-as-you-go Blaze plan.
- Lifecycle: Some products have shutdown dates, such as Firebase Dynamic Links and Firebase Extensions, so the roadmap is controlled by the vendor.
- Exit effort: Moving later means exporting data service by service and rewriting client code.
Before relying on this model, confirm the current Blaze billing terms, data location options, and shutdown notices directly in the Firebase documentation for your regulatory context.
Appwrite Cloud is the hosted edition of the same BSD-3-Clause platform you could run yourself. The vendor operates the infrastructure, so the APIs and SDKs match a self-hosted install, but capacity, backups, and region choices follow the cloud plan. Plans are Free, Pro from $25 per month, and custom-priced Enterprise, according to Appwrite's pricing page.
- Free plan: Up to 2 projects, 75K monthly active users, and projects paused after 1 week of inactivity.
- Free freeze behavior: When a Free project reaches a resource limit, it freezes and the Console goes read-only, so the application can stop accepting writes until the limit is resolved or the plan changes.
- Pro plan: Includes 2 TB bandwidth, 150 GB storage and 200K monthly active users per project, plus daily backups. Overages are charged, with email alerts at 75% and 100% of limits and an optional organization budget cap.
- Enterprise: Custom pricing and terms, so the quote defines support, data handling, and region commitments.
- Availability: Confirm the uptime commitment, backup retention, and region options in the contract rather than assuming them from the plan name.
Review the freeze rules and overage settings with the vendor before launch, because they determine what your users see when traffic grows.
Self-hosted Appwrite runs the appwrite/appwrite:2.5.0 image, or the official Helm chart, inside your own cloud account, data center, or private network. Your organization controls the data path, the upgrade schedule, and the backup design, and it carries the operating work that Appwrite Cloud and Firebase would otherwise absorb. The installation guide lists 2 CPU cores, 4 GB of RAM, 2 GB of swap, and Docker Compose version 2 as the starting requirements.
- Single-host install: The Docker setup runs PostgreSQL, Redis, Traefik, ClickHouse, the API, workers, realtime, console, and an Open Runtimes executor, and the setup wizard listens on port 20080.
- Kubernetes: The Helm chart runs the built-in PostgreSQL, Redis, ClickHouse, and object storage with a single replica and no failover, so production data should use managed services or operators.
- Availability: High availability is your job to design. Plan replicated databases, object storage, backups, and tested restores before go-live.
- Upgrades: Appwrite releases often (2.0 on September 4, 2026, and 2.5.0 on October 13, 2026), so schedule a tested upgrade process.
- Staffing: Your team or a implementation partner owns patching, monitoring, capacity, and incident response.
Confirm the support model, the replication design, and the upgrade path for your environment before committing, since no vendor support is implied by the open-source license.
What each option costs to run over time
Firebase bills by usage across several meters, while self-hosted Appwrite moves the cost into servers, backups, monitoring and the people who operate the stack. Appwrite Cloud sits between the two, with its own plan structure. Separate the one-time work of migration and rewrites from the costs that recur every month or year.
Firebase usage-based billing drivers
Firebase costs follow usage: Firestore reads and writes, Authentication monthly active users, Cloud Storage, Cloud Functions invocations and Hosting transfer. Cloud Storage for Firebase has required the pay-as-you-go Blaze plan since changes announced in September 2024, so file storage and functions are tied to metered billing. Ask your team to pull the last twelve months of billing by service, since the meters that grow fastest are the ones to model first.
Appwrite Cloud plan costs
Appwrite Cloud's Pro plan starts at $25 per month and includes 2 TB bandwidth, 150 GB storage and 200K monthly active users per project, with daily backups. Overage charges apply beyond those limits, and the optional organization budget cap helps keep spend predictable. Free projects freeze in read-only mode when they hit a resource limit, so a production app should not run on that tier.
Self-hosted server capacity
Appwrite's installation guide sets minimums of 2 CPU cores, 4 GB of RAM and 2 GB of swap, with Docker Compose version 2. Those minimums describe a test or small install, not a production sizing, so ask your platform team to size the node pool for expected traffic, realtime connections and functions. Compute, block storage and egress are billed by your cloud provider or data center, and they recur every month.
Backups, storage and high availability
The Helm chart docs state that built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without failover, so production data usually needs managed services or operators. Those services, plus backup storage and restore testing, are recurring costs that Appwrite Cloud includes in its Pro plan. Ask vendors and your own team to quote replicated databases, off-site backups and a tested restore procedure as separate line items.
Monitoring, patching and upgrades
Appwrite released 2.0 on September 4, 2026 and 2.5.0 on October 13, 2026, and 2.0 replaced the engine underneath, so upgrades carry a real migration effort. Plan recurring time for monitoring the Docker or Kubernetes services, applying security patches and testing each upgrade in staging. The one-time cost is building that pipeline, and the recurring cost is running it every release cycle.
Migration and SDK rewrite effort
Migration is mostly one-time work: moving users with their password hashes, importing Firestore data, moving files and rebuilding security rules as Appwrite permissions. Client SDK calls and server functions also need rewriting, and that effort scales with the size of the app's Firebase surface. Ask for a fixed-scope quote that lists each service, the users and data volumes covered, and the tests that prove parity before cutover.
People who operate the stack
Self-hosted Appwrite removes the metered bill but adds an operations role that Firebase does not require. Appwrite is BSD-3-Clause, and the community supports the project, so there is no vendor contract to fall back on for incidents. Ask whether the cost of on-call coverage, a support retainer or internal staffing is included in the comparison, because that line often outweighs infrastructure spend.
How a move from Firebase to Appwrite typically unfolds
The sequence moves a Firebase project into a self-hosted Appwrite instance in an order that tests identity and data before any client app is switched over. Each step ends with a check that tells you whether the next step can start.
Inventory every Firebase service in use
List each Firebase product the apps depend on: Firestore or Realtime Database, Authentication providers, Cloud Storage buckets, Cloud Functions, Hosting, Messaging and any installed extensions. Record which client SDK calls each app makes and which Cloud Functions triggers run on database or auth events. Your team, with input from the app owners, produces this inventory. It is done when every product has an owner, a target Appwrite service and a note on whether Appwrite's migration carries it. Anything without a target goes on a separate list for rebuilding.
Prepare the Firebase service account and Appwrite project
Create a service account in the Firebase project with the roles Appwrite's Firebase migration requires, and generate its key file. Confirm the role list against the current Appwrite Migrations documentation before you grant anything, because the required roles are set by Appwrite and may change between releases. On the self-hosted Appwrite instance, confirm the version is 2.5.0 or later and that the target project exists with the database service enabled. It is done when a test connection from the Appwrite Console to the Firebase project succeeds and the key is stored in your secrets manager.
Import users and test password hash compatibility
Export Auth users from Firebase with the Firebase CLI, which includes password hashes and the project's modified scrypt parameters, then run the Appwrite Firebase migration for users. Appwrite's Users API accepts modified scrypt hashes, so existing passwords can verify without a forced reset. Sign in with a sample of accounts from each provider type on the new instance. It is done when those test accounts authenticate, social provider accounts are listed for re-linking where needed, and the team has written down which users must reset a password or re-authenticate.
Move Firestore data and Storage files
Run the migration for Firestore collections and Cloud Storage files into Appwrite Databases and Storage buckets. Documents are converted into Appwrite's collection and document model, so nested maps and arrays need a flattening or relation decision before the data is final. Compare record counts per collection and spot-check file sizes and content types against the Firebase console. It is done when the counts match for each collection, the exceptions are listed with a fix or an accepted loss, and the data-model changes are signed off by the application owners.
Rebuild Functions, realtime and security rules
Recreate each needed Cloud Function as an Appwrite Function running on the Open Runtimes executor, and recreate triggers as event subscriptions or scheduled jobs. Replace Firebase security rules with Appwrite permissions set per collection, bucket and document, and write tests that show a user cannot read another user's records. Rebuild realtime listeners against Appwrite's Realtime channels, since Realtime Database data does not migrate and must be redesigned. It is done when each function has a passing test and each permission rule has a matching test that denies the access it should deny.
Test the migrated stack and confirm recovery
Run the apps against the Appwrite instance in a staging environment with migrated data, covering sign-in, reads and writes, uploads, function calls and realtime updates. Load test at the expected concurrency, and confirm the single-replica datastore limits in the Helm chart documentation are covered by backups, managed services or operators. Test a restore from backup. It is done when the test checklist passes, the restore has been demonstrated on a copy, and the open issues are ranked with owners.
Cut over and decommission Firebase access
Switch the apps' SDK endpoints and project IDs to the Appwrite instance in a planned window, keep the Firebase project read-only for a rollback period you agree in advance, and monitor sign-in errors and function failures. Do a final delta export of users and data written during the window if the team needs it. Once the rollback period closes, remove Firebase keys from the apps and CI pipelines and revoke the service account. It is done when production traffic runs on Appwrite, the Firebase service account is revoked, and the cutover record lists what was not migrated and how users were informed.
Questions buyers ask before choosing Appwrite over Firebase
Can a Firebase to Appwrite move avoid forcing users to reset their passwords?
It can, but only if the password hashes survive the move, and that depends on the hash type your Firebase project uses. Firebase Auth uses a modified scrypt algorithm by default, and the Firebase CLI exports hashes together with their parameters. Appwrite's Users API accepts imported Scrypt modified hashes, so a matching export can keep sign-in working without a reset. Confirm this with your own export before planning a cutover: check the hash algorithm and parameters in the file, and test a sample of real accounts against a staging Appwrite instance. Users created with social providers or other sign-in methods may need a different path, so review those separately. See the Appwrite Users API reference for the accepted formats.
How long does a Firebase to Appwrite migration take?
No duration is supplied for this migration, so the answer depends on your project. The main drivers are the volume of Firestore documents and Storage files, how many Auth users need hash verification, how much your data model changes, and how many Firebase features sit outside the migration path. Appwrite's built-in Migrations feature handles users, Firestore data and files, but schema mapping, permission rebuilding and client SDK changes are work your team or a partner must plan. Ask any provider for a written scope that lists each data set, its size, the test cycles and the cutover window, so the timeline follows from that scope rather than from a generic estimate.
What does the internal team need to contribute to the migration?
The team needs people who own the Firebase project, its security rules and its service accounts, plus engineers who know the client apps and the data model. Appwrite's Firebase import requires a service account with specific roles, so someone with Firebase IAM access must create it and remove it afterward. Product owners must decide which Firebase behavior changes are acceptable, such as dropping Realtime Database data or rewriting nested collections. Operations staff need to take over the Docker Compose or Helm deployment, backups and upgrades. Budget time for testing with real users, since authentication and permissions are where most surprises appear.
Can our own engineers run this migration without outside help?
Yes, a capable team can run it in-house, and Appwrite's self-hosting guide and migration documentation cover the main steps. The deciding factors are whether your engineers have run production Linux and container workloads, whether they can own the backups and patching that a self-hosted stack requires, and whether they have time to rebuild security rules as Appwrite permissions. Appwrite's Helm chart documentation states that its built-in datastores run a single replica without failover, so production planning needs managed databases or operators, which adds design work. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your infrastructure under a fixed scope agreed in writing, and offers retainers for ongoing upgrades and support. Either route should start with a written scope.
Which Firebase features have no direct equivalent in Appwrite?
Appwrite covers many of the same areas, including Auth, Databases, Storage, Functions, Messaging and Realtime, but some Firebase features do not move directly. Appwrite's migration documentation lists Realtime Database data, nested data structures, OAuth sessions and Cloud Functions as items that do not transfer automatically. Firebase Hosting, Dynamic Links and Extensions also need separate replacements or a retirement plan, and Dynamic Links shut down on August 25, 2025. Your Firestore data model will need to be reshaped, because Appwrite's databases are not a one-to-one copy of collections and subcollections. Inventory each Firebase service your apps call before you commit to a scope.
What recurring costs replace Firebase's usage bills after a move?
The recurring costs shift from per-operation billing to the infrastructure and people that run the stack. These include the servers or cluster, storage, backups, monitoring, and the staff time to patch and upgrade Appwrite. Appwrite Cloud is a separate option with its own plans; its pricing page lists a Pro plan from $25 per month, so compare that figure with your own usage and the self-hosted cost model. One-time costs include the migration and client rewrite. Ask any provider for a quote that separates one-time work from monthly operating assumptions, and model your current Firebase usage against both options before deciding.
Does moving to self-hosted Appwrite change who is responsible for uptime and security patches?
Yes, responsibility moves to your organization or the partner you hire. On Firebase, Google operates the hosted services. When you self-host Appwrite, your team owns the host operating system, container images, database engine, backups, TLS certificates and upgrades. Appwrite's Helm chart documentation describes single-replica built-in datastores, so high availability depends on the production architecture you choose. Clarify who receives release notes, who tests upgrades such as the 2.0 migration, and who responds to incidents. Community support is available for open-source releases, so a support plan should be part of the scope if your service levels require one.
How DeployOpen helps evaluate, implement and migrate
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Firebase to Appwrite decision, we start from written requirements for auth, data, files, functions and realtime, then work through what moves and what must be rebuilt.
How we scope
- Written scope covers which Firebase services move, which stay and which are retired.
- We inventory auth methods, Firestore collections, Storage buckets and Cloud Functions in use.
- Data location, residency and Appwrite deployment target are confirmed before any engagement starts.
How we build
- We deploy Appwrite in your environment, using the Docker or Helm path that fits your operations model.
- We test the Firebase migration on a copy, checking user password hashes and imported Firestore data.
- We rebuild permissions, realtime listeners and functions, and test them against your application flows.
How we hand over
- You receive architecture notes, runbooks for upgrades, backups and restores, and a record of decisions.
- We document which Firebase features did not carry over and how each gap was handled.
- Handover includes a walkthrough with your engineers so they can operate the platform independently.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover Appwrite version upgrades, including the release cadence you agree on.
- Ask what support, patching and on-call coverage the written scope includes before signing.
