Which backend fits your app: Firebase or self-hosted Supabase
Firebase fits teams that want a managed Google service built around a NoSQL document model, with little operational work and Google running the infrastructure. Self-hosted Supabase fits teams that want Postgres, relational queries and control over where the data runs, and that are prepared to operate the stack themselves. Most evaluations start with a trigger: a renewal, a move to the pay-as-you-go Blaze plan for Cloud Storage or Functions, the Dynamic Links shutdown on August 25, 2025, the Extensions shutdown on March 31, 2027, or a residency requirement that Firebase Authentication cannot meet because it processes data only in the United States. Identify which of these actually drives your decision before you compare features.
Start by mapping your current data. If your Firestore collections are mostly self-contained documents read by key, the document model may suit you and the move to tables will cost more than it saves. If your app depends on joins, reporting queries, or constraints across records, Postgres will likely reduce the application code you write. Expect to rewrite client SDK calls, since the Firebase SDKs and Supabase client libraries differ, and to replace Firestore security rules with Postgres row level security policies. Ask your team to write those policies for three or four representative tables before committing to a plan.
Three decisions remain, and they should be settled in writing. First, operating capacity: confirm who will patch, back up and upgrade the Docker deployment, since self-hosted Supabase is community-supported and does not include the managed backups or point-in-time recovery of the hosted product. Second, residency: confirm the region for the server, database and object storage, and check that auth, data and files will all sit in the same jurisdiction. Third, password hash migration: export a test set of Firebase Auth users with their scrypt parameters and confirm that your target can verify them, so users do not face forced resets at cutover. If any of these three cannot be answered, the decision is not ready.
Which option fits which scenario
This table maps common situations to the platform that usually fits best and the condition that decides it. Read each row against your own data shape, residency rules and operating capacity, since the right answer depends on those conditions rather than on either product being better overall.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Existing Firestore app with document-shaped data | Firebase stays, or a staged move | Nested, schema-flexible documents with listeners on collections change the rewrite cost; a move to Postgres tables means redesigning the data model first |
| Relational app needing joins and reporting | Self-hosted Supabase | Postgres gives SQL joins, constraints and reporting views; Firestore needs denormalization and data copies for the same queries |
| EU residency for auth and data together | Self-hosted Supabase in an EU data center | Firebase Authentication processes data only in the United States, so keeping users and records in one EU location requires self-hosting or another platform |
| Small team without platform engineers | Firebase, or a hosted Supabase plan | Self-hosting means someone patches, backs up and upgrades several services; Supabase's self-hosting docs describe community support only |
| Enterprise sign-in needs (SAML or OIDC, audit) | Depends on the identity design | Confirm which SSO protocols and audit features your chosen auth layer supports in your edition before committing to a migration |
| Team already runs Kubernetes or Docker operations | Self-hosted Supabase | Docker Compose is the documented self-hosting method; the Kubernetes routes are community-maintained, so confirm support expectations |
| Strong need for a single vendor for support contracts | Firebase or a hosted vendor plan | Self-hosted Supabase is community-supported, so enterprise support must be bought separately if your policy requires a vendor contract |
How the move from documents to tables changes your app
The biggest engineering effort in a Firebase to Supabase move is usually the data model change, not the hosting. Firestore collections and nested documents have no direct equivalent in Postgres. Each collection becomes a table, and each nested map or subcollection either becomes a child table with a foreign key back to its parent or a jsonb column when the data is read as a unit. The team must decide, entity by entity, which shape fits the queries the app actually runs. Denormalized copies that Firestore required for cheap reads often become joins, and those joins need indexes that someone has to design and review. Plan this mapping on paper before any data is copied, and confirm it against the queries in your client code, not against the old Firestore console.
Client code changes with the model. Firestore SDK calls for document reads, collection queries and onSnapshot listeners are replaced by requests to PostgREST through the Supabase client, or by Postgres changes delivered through Supabase Realtime. Filters, ordering and pagination map onto different query syntax, and relational reads need explicit embedding rules. Expect every data access path in the front end to be rewritten and tested, not only the schema. Firebase security rules have no direct file-to-file translation either. In Supabase they become Postgres row level security policies that the team writes, reviews and tests against real roles, including the anonymous and authenticated roles that PostgREST uses. Treat the policy suite as the new authorization layer and keep tests for every table that clients can reach.
Data location deserves an early decision. A Cloud Firestore database's location cannot be changed after it is provisioned, so the region chosen at setup constrains where documents live for the life of the database. For a self-hosted Supabase stack, the residency question moves to the hosting site you choose, so confirm which data center, backup location and log destinations will hold tables, files and auth records before the schema is finalized. Ask the Supabase community or your infrastructure provider to confirm any remaining region constraints for your deployment, and document the answers as part of your residency record.
Data location, hosting and compliance implications
Where data sits is often the first constraint a regulated team hits with a backend as a service. Firebase fixes several location choices early and keeps authentication in the United States, while self-hosted Supabase places every component in an environment the team chooses. The cards below cover what to verify, who operates each layer, and where DeployOpen's role stops.
Firebase Auth location limits
Firebase Authentication processes data only in the United States, even when Cloud Firestore uses a European location. For a team with an EU residency requirement, user identifiers, credentials and sign-in records can therefore sit outside the region where the rest of the app data is stored. Confirm this against Firebase's current privacy documentation before a data flow diagram is signed off, and record the result in the data protection assessment.
Firestore location is permanent
A Cloud Firestore database's location cannot be changed after it is provisioned. Choosing the wrong region is therefore not a setting to fix later. Migration means provisioning a new database in the target location and moving data across, which is effort the team pays for in engineering time and downtime planning. Put the location decision in the architecture record before the first production write.
Supabase Cloud region selection
Each Supabase Cloud project is hosted in one main region chosen from 17 AWS regions. The region is picked at project creation, so the same residency review applies to the hosted option as to Firebase. Check that the chosen region covers the database, Storage and Auth service for the project, and confirm with Supabase which data, backups and support access stay in that region before relying on it for regulated data.
Self-hosted placement control
Self-hosted Supabase runs from Docker Compose on infrastructure the team chooses: its own cloud account, a data center or an air-gapped network. Postgres, Auth, Storage and Realtime stay inside that boundary, and no vendor-hosted control plane sits in the data path. The team must still confirm where backups, logs and analytics are sent, because optional Logflare and Vector components can be configured to ship data elsewhere.
Operator responsibilities for controls
With self-hosting, the operator owns access control to hosts, network segmentation, TLS, secret rotation, patching and backup encryption. Supabase's self-hosting documentation states that the community provides support, and it does not operate the environment. Write down who holds each control, including the team that rotates the JWT keys and the one that restores from backup, so an auditor can trace each control to a named owner.
Evidence and attestation boundaries
DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration baselines, access reviews and backup test records. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Ask any implementation partner to state this boundary in the written scope, and ask the auditor which evidence formats it accepts before work begins.
What the team must operate on each side
With Firebase, Google runs the underlying infrastructure for Cloud Firestore, Authentication, Cloud Storage, Cloud Functions and Hosting. Your team does not patch database servers, size clusters or run the auth service, but it still owns a set of configuration and cost duties that shape day-to-day work.
- Security rules: Your team writes, tests and deploys Firestore and Storage security rules, which become the main access control layer for client apps.
- Indexes: Composite indexes for queries are defined and maintained by your team, and index changes need review alongside data model changes.
- Blaze billing: Cloud Storage and Cloud Functions require the pay-as-you-go Blaze plan, so someone must own budget alerts, usage reviews and billing account access.
- Quotas and limits: Your team tracks service quotas and per-operation pricing as traffic grows, and designs clients to avoid unnecessary reads and writes.
- Lifecycle changes: Your team must track Firebase deprecations, such as the Extensions shutdown on March 31, 2027, and plan replacements.
Confirm current quotas, billing terms and support entitlements in your Google Cloud account before committing, since these are set by the vendor and change over time.
Self-hosting moves the platform into your own environment. The Docker guide names Docker Compose as the recommended method, and the minimum requirements are 4 GB RAM, 2 CPU cores and a 40 GB SSD, with 8 GB RAM, 4 cores and 80 GB recommended. Kubernetes deployments are possible through a Helm chart or the Supabase Operator, but those are community projects.
- Service operation: Your team runs Studio, the API gateway, Auth, PostgREST, Realtime, Storage, Edge Runtime, the connection pooler and the Postgres database.
- Secrets: Never start with the placeholder values in
.env.example. Generate secrets and the JWT key pair with the provided scripts, and protect Studio withDASHBOARD_PASSWORD. - Release pulls: Each Docker configuration release bundles specific upstream versions, such as Auth v2.197.0 in 0.8.3, so your team pulls and recreates those services on its own schedule.
- Backups and recovery: Managed backups and point-in-time recovery are not available in self-hosting, so your team designs, tests and monitors its own backup and restore process for Postgres and Storage.
- Support model: Self-hosted Supabase is community-supported through GitHub, Discord and Reddit, not backed by a vendor SLA. Enterprises are directed to contact Supabase's Growth Team for commercial options.
Before committing, confirm which support arrangement, if any, you will rely on, and who on your team holds on-call duty for database and auth incidents.
The operating split changes who carries pager duty, patch windows and recovery testing. A useful way to read the two sides is to assign each recurring task to a named role before cutover, since the work shifts from a provider's operations to your own staff.
- Platform engineers: On Supabase, they own host sizing, container upgrades, reverse proxy and TLS, and monitoring of the Postgres instance.
- Application developers: On Firebase, they own rules, indexes and client query design. On Supabase, they own SQL schema, row level security policies and Edge Function code.
- Security team: They review secret rotation, Studio access, network exposure and the risk of a one-way Storage migration that requires a backup first.
- Finance and procurement: They track Blaze spend against the server, storage and staff cost of self-hosting, and confirm contract terms for any paid support.
- Auditors and compliance leads: They need evidence of change control, backups and access reviews, which self-hosting places inside your own records.
Agree this matrix in writing with named owners and review dates before the migration plan is approved.
How a move from Firebase to self-hosted Supabase proceeds
The sequence moves Firebase users, documents and files into a self-hosted Supabase project with a schema, auth and access rules your team can operate, and ends with Firebase retired after a tested cutover. It separates the parts Supabase tooling covers from the services that need rebuilding.
Inventory data, users and files
Your team lists every Firestore collection, Auth user population, Storage bucket and the apps that read or write them, and notes which Realtime Database paths, Cloud Functions and Extensions also depend on Firebase. A platform engineer and the app owners sign off the list. Done when each data source has an owner, a volume estimate and a named migration path, with the gaps (Realtime Database, Functions, Extensions) flagged for separate rebuilding.
Design the Postgres schema
Firestore's nested documents and subcollections are mapped onto Postgres tables, keys, foreign keys and JSON columns where the data is genuinely unstructured. Your data architect decides how references replace document paths and how the auth.users table links to application profiles. Done when a reviewed schema covers every collection in the inventory and each mapping decision is recorded.
Test password hash import
Export a sample of Auth users with their password hashes and the project's modified scrypt parameters using the Firebase CLI, then import them into a test self-hosted Supabase instance and confirm that sign-in works without a forced reset. Your security team checks how the hash parameters are stored and who can read the export. Done when a test account from each sign-in method logs in successfully and the export file is handled under your key management rules.
Rewrite client calls and row level security
Your front-end and mobile developers replace Firebase SDK calls with supabase-js or the relevant Supabase client, and translate Firestore security rules into Postgres row level security policies tied to the authenticated user. Security engineers review each policy with negative tests that try to read or write another user's rows. Done when every read and write path in the app has a matching policy and the negative tests fail as expected.
Run the migration in a staging environment
Use Supabase's documented Firestore path and the supabase-community firebase-to-supabase scripts to load collections, Auth users and Storage files into a staging project, then compare record counts, file checksums and sample queries against Firebase. Because these scripts are community-maintained, your team confirms their behavior against its own data before use. Done when reconciliation reports match for every collection, user population and bucket.
Rebuild functions, realtime and extensions
Cloud Functions move to Supabase Edge Functions, Realtime Database listeners are rebuilt on Supabase Realtime over Postgres changes, and each deployed Firebase Extension is replaced by an explicit function or service. Developers test each trigger and listener separately, since the Supabase migration tooling does not cover these services. Done when every function, listener and extension in the inventory has a tested replacement or a documented decision to drop it.
Cut over and retire Firebase
Your team freezes writes in Firebase, runs a final incremental export and import, switches DNS, client configuration and any webhook endpoints to the self-hosted Supabase project, and keeps Firebase read-only for a rollback window agreed in advance. Operations staff confirm backups, monitoring and patch procedures are running on the production stack. Done when production traffic is served from Supabase, the rollback window closes without incident, and Firebase resources are deleted under a written decommission record.
How the cost of each option is built
Firebase costs are usage-based, so the bill moves with traffic and data volume rather than with a fixed contract. The components that usually drive it are Firestore reads, writes and deletes, Firebase Authentication monthly active users, Cloud Storage for Firebase, Cloud Functions invocations and compute, and Hosting data transfer. Cloud Storage for Firebase needs the pay-as-you-go Blaze plan, and Cloud Functions is also tied to Blaze, so the plan itself is a recurring commitment before usage starts. Ask for a written estimate that lists each of these meters separately, with the usage assumptions behind it (read and write counts per active user, peak concurrency, average file size and monthly egress), so finance can test which meter dominates.
Self-hosted Supabase replaces usage meters with infrastructure and people. The recurring costs are the servers or cloud instances running the Docker Compose stack, the database and file storage volumes, backup storage and the monitoring and log retention you choose to run. The one-time costs are the migration of Firestore data, Auth users and Storage files, the rewrite of client SDK calls and security logic, and testing. The most often underestimated recurring cost is labor: someone must pull each Docker configuration release, review changelogs such as the one that flags one-way Storage database migrations requiring a backup first, and keep Postgres, Auth, PostgREST and Realtime current. Supabase Cloud's Pro plan is listed from $25 per month, per the Supabase pricing page, but that is a hosted plan, not a self-hosting cost.
In the written quote, ask the vendor or implementation partner to separate one-time migration and rewrite, infrastructure sized to your user and data profile, backup and restore testing, and ongoing operations such as patching, on-call coverage and support. Ask who pays for each item and whether support is community-only or contracted. Also ask what drives the price up: data volume, number of security rules to translate into row level security policies, realtime connection counts and the number of Edge Functions. A sound quote states its assumptions, so you can rerun the comparison when your traffic changes.
Questions buyers ask before switching from Firebase to Supabase
How much does a migration from Firebase to self-hosted Supabase cost?
No single figure applies, because the cost depends on the data you hold, how much code you rewrite and who does the work. Expect one-time costs for the migration itself, the rewrite of client SDK calls to Postgres queries and PostgREST, and security policy work, plus recurring costs for servers, storage, backups and the people who patch the stack. Ask any provider for a fixed-scope quote that separates these components, and ask what is included in the one-time work versus the monthly operating load. Your Firebase bill is usage-based, so compare it against the full self-hosted operating model, not only the server line.
How long does a switch from Firebase to Supabase take?
The timeline is set mainly by how many Firebase services you use, how large your Firestore data set is, how much of your client code depends on Firestore listeners and security rules, and how many users must move without a password reset. Supabase documents a path for Firestore data, Auth users and Storage files, but the data-model redesign and testing usually take longer than the copy itself. Agree on a written scope and a cutover plan before work starts so the timeline reflects your inventory rather than an estimate.
Can our own engineers migrate from Firebase to Supabase without outside help?
Yes, many teams do, provided they have Postgres experience and time to redesign the data model. The Supabase documentation covers exports and imports, but the hard parts are converting nested documents into relational tables, rewriting Firestore security rules as Postgres row level security, and replacing Cloud Functions and listeners. If your team lacks that skill set or cannot pause feature work, an implementation partner can take a fixed-scope piece, such as the migration or the access rules, while your engineers keep ownership of the application.
Do password hashes move from Firebase Auth to Supabase without forcing resets?
Often yes, but only if the hash parameters are carried over. Firebase Auth uses a modified scrypt algorithm by default, and the Firebase CLI exports the hashes along with their parameters. Supabase's documented path imports Auth users into the auth.users table using the project's scrypt parameters. Test a sample of accounts on a staging project before cutover, and confirm which sign-in methods, such as social providers, need to be re-linked, because those do not move as password hashes do.
Should we choose Supabase Cloud or self-host Supabase for data control?
Self-hosting gives you control over where data and keys live, which matters most when residency rules or contractual terms restrict hosted processing. Supabase Cloud lets each project pick one main region from a list of AWS regions, which may be enough for some requirements but is a provider decision you must verify against your own obligations. Self-hosting shifts operations, backups and upgrades to your team. Note that Supabase's self-hosting docs list managed backups, point-in-time recovery and the Management API as unavailable, so plan your own backup and recovery.
What must our team maintain after a self-hosted Supabase go-live?
Plan for recurring work in several areas: applying Docker Compose configuration releases and the upstream service versions they pin, such as Auth, PostgREST and Realtime, monitoring the host, managing secrets and the JWT key pair, rotating credentials, and running and testing backups. Some releases require a database backup before updating, so upgrades need a rehearsed procedure. Supabase's self-hosting docs describe the product as community-supported, so you should decide in advance who handles incidents and whether you need a retainer for upgrades and continuous testing.
What happens to Firebase features that Supabase does not replicate directly?
Some Firebase features need a different design rather than a direct port. Realtime Database JSON trees become Postgres tables with Supabase Realtime subscriptions, Cloud Functions become Edge Functions on the Deno-based Edge Runtime, and Firestore security rules become row level security policies. Confirm each feature against the Supabase documentation and test it in staging, because behavior around listeners, offline caching and trigger timing may differ and should be validated for your application.
Why does the open-source license matter for this switch?
Supabase's main repository is licensed under Apache-2.0, which lets you run and modify the software in your own infrastructure. The license does not cover support, uptime or upgrade effort, which remain your responsibility or a contracted provider's. Read the license with your legal team, and confirm which components you use, since the self-hosted Docker configuration is a separate release stream that pins upstream versions of its own.
How DeployOpen helps evaluate and implement the switch
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and supports self-hosted Supabase inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as a retainer. DeployOpen does not publish a price list. A quote follows from the written scope, so the useful first step is to put the decisions in front of us in writing: which Firestore collections map to which Postgres tables, which Auth users and password hashes must move without reset, which Storage buckets and access rules come across, and which Cloud Functions become Edge Functions.
On the Supabase side, the work covers the Docker Compose stack, including Studio, the Envoy gateway, Auth, PostgREST, Realtime, Storage, Postgres, Edge Runtime and Supavisor, along with the .env secrets and JWT key pair, Studio protection through DASHBOARD_PASSWORD, backup and restore routines, and a documented upgrade path. Because self-hosted Supabase is community-supported, the operating model matters as much as the first deployment. Confirm with us, and with your own operations team, who will pull new configuration releases, who restores from backup and how often that is tested, and who answers when an upstream service ships a security fix. Security testing of the application, its APIs and its row level security policies, and compliance readiness work that prepares systems, controls and evidence for an independent assessor, can be scoped alongside the migration. DeployOpen prepares that evidence but does not issue audit reports or certifications.
