Does self-hosted Supabase cost less than Firebase Blaze?
The honest answer is that it depends on usage, team capacity and the one-time migration, and no figure in this comparison should be read as a universal saving. If your Firebase bill grows with Firestore reads and writes, Authentication MAUs, Storage, Cloud Functions calls and Hosting transfer, or if Cloud Storage for Firebase forces you onto the pay-as-you-go Blaze plan and you want that requirement gone, the decision turns on three cost lines: the servers you run, the people who operate and patch them, and the one-time work to move data, users and files. The open-source options carry no license fee, since Supabase is Apache-2.0, Appwrite is BSD-3-Clause and PocketBase is MIT, so what you pay for is infrastructure and staff time.
Infrastructure has a stated floor. Supabase's Docker self-hosting guide lists minimum requirements of 4 GB RAM, 2 CPU cores and a 40 GB SSD, with 8 GB RAM, 4 cores and 80 GB recommended. Appwrite's installation guide requires 2 CPU cores, 4 GB of RAM and 2 GB of swap. Those are starting points, not sizing for your load, and your real cost depends on storage growth, backups, and whether you run the production datastores on managed services, which Appwrite's Helm chart docs recommend because its built-in datastores run a single replica. For comparison only, Supabase Cloud and Appwrite Cloud Pro both start from $25 per month according to their pricing pages. Ask a provider for a quote that separates compute, block storage, object storage, backup retention and a second environment for staging.
The recurring cost that most often surprises teams is labor. Supabase's self-hosting docs describe self-hosted Supabase as community-supported, so your engineers own upgrades, including Docker configuration releases that pin specific Auth, PostgREST and Realtime versions, and any one-way database migrations flagged in the changelog. Budget for backup testing, since managed backups and point-in-time recovery are not available when self-hosting. Confirm with your team who will be on call for the stack, how often you will apply releases, and whether you need a retainer for patching and support, which DeployOpen offers as ongoing support rather than as a fixed price.
Which cost components change between Firebase and self-hosting
This table sets each Firebase cost driver against the matching self-hosted cost, and marks whether it is paid once or on an ongoing basis. Read it as a checklist for building a like-for-like estimate before you ask for quotes. The main takeaway is that Firebase bills mostly by usage, while self-hosting moves spend toward servers, backups and the people who run the stack.
| Cost component | Commercial side (Firebase) | Self-hosted side (Supabase, Appwrite or PocketBase) | One-time or recurring |
|---|---|---|---|
| Database usage | Billed per Firestore reads, writes and deletes, which climb with query and listener volume | Billed as CPU, memory and disk on servers you size; cost follows capacity, not operations | Recurring |
| Authentication | Auth charges depend on monthly active users, so growth raises the bill directly | Auth runs inside the stack you host; cost follows server capacity and email delivery | Recurring |
| File storage and transfer | Billed for stored bytes, downloads and Storage operations, all on the Blaze plan | Billed as disk or S3-compatible storage plus outbound bandwidth from your provider | Recurring |
| Functions and hosting | Billed for function invocations, compute time and Hosting transfer | Runs on the same servers or a container platform; cost is shared capacity you already pay for | Recurring |
| Hosts and storage | No server cost, but usage meters rise with each feature added | Cloud VMs or hardware, load balancing and block storage, sized for peak load and headroom | Recurring |
| Backups and recovery | Included in the managed service; exports to Cloud Storage are billed separately | Snapshot storage, off-site copies and restore testing, which you build and pay for | Recurring, with setup one-time |
| Migration and rewrite | Little or none on the Firebase side, but teams keep building against SDKs and rules | Data export, user import with password hashes, client SDK changes and security rule rewrites | One-time |
| Operations, patching and support | Google operates the platform; your team handles application-level changes only | Staff time for upgrades, security fixes and monitoring, plus paid support if you contract it | Recurring |
What moves the comparison most
Firebase bills scale with usage, while a self-hosted stack bills largely with the hardware and people behind it. The drivers below decide which side of that split your workload falls on, and each one should be priced from your own usage data rather than from assumptions.
Monthly active users and auth volume
Firebase Authentication pricing and Supabase or Appwrite user limits both depend on how many people sign in each month. On a self-hosted stack, user count mainly changes the database size, session load and email delivery workload rather than a per-user line item. Check your current monthly active user count, peak sign-in rate and whether you need enterprise SSO, since each of those affects the server size and any identity add-on you choose.
Read and write patterns
Firestore bills per document read, write and delete, so chatty listeners and wide queries can dominate the bill. In self-hosted Supabase, the same traffic lands on Postgres, so the cost shows up as CPU, memory and connection pressure on a server you size. Indexes, query shape and how many clients hold realtime subscriptions open decide whether a modest server is enough. Profile a typical day of reads and writes before comparing.
File volume and egress
Firebase Cloud Storage and Hosting charge for stored bytes and data served to users, and that egress charge often grows faster than anything else. Self-hosted, files sit on local disk or S3-compatible storage that you pay for by capacity, and bandwidth depends on your server network and any object store you use. Measure total stored gigabytes, daily downloads and the share of traffic that is media, then ask whether backups of that storage are included in your estimate.
Availability requirements
A hosted service carries uptime and backup responsibility for you, while a self-hosted stack moves that duty to your team. Appwrite's Helm chart docs state that its built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without failover, so production usually needs managed databases or operators, which adds recurring cost. Decide your recovery targets first, then price the replicas, backups and standby capacity those targets require.
Number of environments
Each environment you need, such as development, staging and production, is a separate Firebase project on the usage bill, but on a self-hosted stack it is another set of servers, databases and storage to patch. Teams that run a lean development copy on a laptop spend less than teams that mirror production. Count the environments you need, whether staging must match production in size, and how often you refresh test data from production.
Existing Postgres and Docker skills
Self-hosted Supabase is Postgres plus a set of services that Docker Compose runs, and Supabase's self-hosting docs describe community support rather than vendor support. A team that already operates Postgres, Docker and TLS can absorb much of that work internally, while a team without those skills will pay an implementation partner or hire for it. Inventory who on your staff can own upgrades, restores and security patches, and ask any partner to quote that ownership explicitly.
What the one-time migration and rewrite cost
The one-time cost of leaving Firebase is the engineering work to move data, users, files and client code, and it is separate from the recurring bill for servers and operations. The work has five parts: exporting Firestore collections, importing Auth users, moving Storage files, rewriting access rules as Postgres row level security, and changing client SDK calls. Supabase publishes scripts in the supabase-community firebase-to-supabase repository for Firestore data, Auth users and Storage files, which gives teams a documented starting point. Confirm with your own team whether those scripts fit your collection shapes before estimating effort.
Password continuity is the step most likely to affect users. Firebase Auth uses a modified scrypt algorithm by default, and the Firebase CLI exports hashes along with their parameters. If those parameters are carried into the target import, users keep their passwords. Appwrite's Users API accepts several imported hash types, including Scrypt modified, so the same export can feed either target. Test the import with a sample of real accounts before cutover, and confirm which sign-in methods and social provider links need to be re-created by hand.
Appwrite's Migrations feature can import Firebase projects, which covers users, Firestore data and files, but it does not move Realtime Database content, nested data structures, OAuth sessions or Cloud Functions. Those items need separate rebuilds on either platform. Effort scales with two things: the complexity of the data model (deep nesting and denormalized documents take more mapping into relational tables) and the size of the client surface area (every SDK call, listener and security rule that the app depends on). A small app with a flat schema is a few weeks of work for a small team, while a large app with many listeners is a longer project. Ask any implementation partner for a written scope that lists each collection, rule set and client call, because that list drives the quote.
How to build the comparison with your own numbers
This sequence turns Firebase's usage-based bills into a like-for-like comparison with self-hosted Supabase, so the decision rests on your workload, your rates and your staffing rather than on list prices.
Export twelve months of Firebase usage by meter
Pull the last twelve months of billing and usage data for every Firebase product in use, broken out by meter: Firestore reads, writes and deletes, storage stored, Authentication monthly active users, Cloud Storage egress, Cloud Functions invocations and compute time, and Hosting transfer. Ask your finance or cloud owner to export the Cloud Billing reports at SKU level so nothing is averaged away. You are done when every meter has twelve monthly values and the total matches the invoices you paid.
Map each meter to its self-hosted resource
For each Firebase meter, name the resource that will carry the same load after migration: Postgres tables and query CPU for Firestore operations, Auth and its database for users, object storage and disk for files, the API and worker containers for functions, and bandwidth out of your own network for hosting and downloads. Note where a meter has no direct equivalent, such as per-operation billing, which becomes a fixed capacity cost. Review the map with the engineers who own the app. You are done when every meter has one named resource and any gaps are written down.
Price servers and storage at your own rates
Use your cloud or data center rates to price the compute, memory, block storage and network needed to run the mapped resources at a peak load you have measured, including a second environment for staging if you plan one. Separate what you pay monthly from what you pay once, such as hardware or setup time. Ask your cloud account team or infrastructure lead to confirm the rates, since list prices change. You are done when each resource has a monthly line item traceable to a rate card and a sizing assumption.
Add backup storage and a restore test
Add the cost of backup retention, off-site copies and the storage that holds Storage objects and database dumps, sized from your current data volume and retention policy. Include the time and compute for a restore test, because a backup you have not restored is not yet a backup. Self-hosted Supabase documents that managed backups and point-in-time recovery are not available, so confirm which backup tooling your team will operate. You are done when a full restore into a separate environment has succeeded and its duration and cost are recorded.
Estimate staffed hours for operations and patching
Estimate the hours your team will spend each month on upgrades, security patches, monitoring, on-call response and capacity work. Self-hosted Supabase is community-supported, and Appwrite's Helm chart docs say its built-in datastores run a single replica without failover, so count the effort for managed databases or operators if you adopt them. Price those hours with your internal loaded rate or the rate of an external provider you are considering. You are done when the hours are listed by activity, each with a named owner, and converted to a monthly cost.
Add the one-time migration as a fixed quote
Treat the migration as a separate, one-time cost. Include the work to move Firestore data into Postgres tables, import Auth users with their password hashes and scrypt parameters, move Storage files, rebuild client SDK calls and security rules, and test cutover. Request a fixed-scope written quote from each implementation partner you consider, with deliverables, acceptance tests and what is excluded, so the figure can be compared directly. Ask each bidder to state its assumptions about data volume and the number of client apps. You are done when each option has a signed-off written scope and a fixed price you can place in the model.
Run a parallel-period comparison before deciding
Run the self-hosted stack beside production for a period you agree in advance, with real traffic copied or replayed where your architecture allows it, and compare measured resource use, error rates and latency against the mapped estimates. Recalculate the monthly cost model with the observed numbers and the staffed hours you actually logged. Keep the Firebase bill running during this period so the two totals describe the same workload. You are done when a written comparison shows the measured monthly cost of each path, the one-time cost, and the open risks, and that document is approved by the owners of cost, security and operations.
Which self-hosted option changes the cost profile
Self-hosted Supabase is delivered as a Docker Compose configuration in the supabase/supabase repository, and its services include Studio, an Envoy API gateway, Auth, PostgREST, Realtime, Storage, imgproxy, postgres-meta, Postgres, the Edge Runtime and the Supavisor connection pooler. The published minimum is 4 GB RAM, 2 CPU cores and a 40 GB SSD, with 8 GB, 4 cores and 80 GB recommended. The default database is Postgres 17, and each configuration release pins specific Auth, PostgREST and Realtime versions that you pull and recreate yourself.
- Many moving services: Removing unused components such as Realtime, Storage or Edge Runtime from docker-compose.yml lowers the footprint, but every removal is your change to test.
- Upgrades carry data risk: The 0.8.3 changelog flags one-way Storage database migrations that require a database backup first.
- Single project only: Self-hosted Studio runs one project, so separate environments need separate stacks.
- No managed backups or PITR: You build backup, restore and retention yourself.
- Secrets are your job: The guide warns against the placeholder values in .env.example and supplies generation scripts.
Confirm with your team whether you will add Kubernetes through a community Helm chart or the Supabase Operator, and who owns patching of each service version.",
Appwrite's installation guide sets a minimum of 2 CPU cores, 4 GB of RAM, 2 GB of swap and Docker Compose version 2. The sample Compose file runs PostgreSQL, Redis, Traefik, ClickHouse, the API, workers, realtime, the console and an Open Runtimes executor for functions. New installs of Appwrite 2.0 provision PostgreSQL by default, with MariaDB and MongoDB still supported. The official Helm chart is published as an OCI artifact, which suits teams already running Kubernetes.
- Lighter minimum, wider stack: The published minimum is smaller than Supabase's recommended size, but the bundled datastores still add memory and disk.
- Single-replica datastores: The Helm chart docs say the built-in PostgreSQL, Redis, ClickHouse and object storage run one replica without failover, so production data should use managed services or operators.
- Optional engines ship disabled: DocumentsDB and VectorsDB need PostgreSQL and MongoDB engines that a stock install does not deploy.
- Frequent releases: Appwrite 2.5.0 arrived on October 13, 2026, so plan a regular upgrade window.
- Hosted comparison: Appwrite Cloud's Pro plan is listed from $25 per month, which gives you a benchmark for what self-hosting must beat.
Confirm the replication, backup and failover design for each datastore before you size the production cluster.",
PocketBase ships as a single Go executable with embedded SQLite in WAL mode, started with ./pocketbase serve. It has no external dependencies and no official Docker image, so the usual deployment is a systemd service on one virtual machine. The FAQ says it scales only vertically on a single server and has no plans for other databases. Its licence is MIT, and the project is developed by a volunteer with no paid team behind it.
- Smallest footprint: One binary, one data directory under pb_data, and no separate database server to patch.
- Vertical scaling only: Growth means a larger machine, and there is no documented horizontal path.
- Pre-1.0 compatibility: The docs do not guarantee backward compatibility before v1.0.0, so upgrades may need manual migration steps from the changelog.
- Backups: Dashboard backups can go to local storage or S3-compatible storage, and the docs warn of slight performance loss during backup.
- Support: Maintenance is volunteer-based with no promised support, so your internal team carries the on-call load.
Confirm whether the app's risk profile and uptime needs fit a single-node design before you commit to it for production.
Who patches and supports the stack after launch
The support model differs more than the license terms do, and it decides who owns patching after launch. Self-hosted Supabase is community-supported: Supabase's self-hosting documentation points operators to GitHub Discussions, GitHub Issues, Discord and Reddit, and directs enterprises to its Growth Team. Appwrite's self-hosted edition is open source under BSD-3-Clause, and the support terms you need should be confirmed directly with Appwrite before you rely on them. PocketBase is volunteer-maintained, and its FAQ makes no promise of maintenance or support beyond what is available. Ask each vendor, in writing, what response channel and commitment applies to your deployment, and record the answer in the decision file.
Release cadence is the operational burden. Appwrite 2.5.0 arrived on October 13, 2026, and the self-hosted Supabase Docker configuration reached 0.8.3 on October 16, 2026. That Docker release flagged security fixes for Storage and Realtime and one-way Storage database migrations that require a backup first. Your team needs a named owner who watches release feeds, tests each Compose or Helm change against a staging copy, takes a database backup before any migration, and pulls and recreates the pinned service images. The skills required are Docker Compose or Kubernetes, Postgres administration, secrets rotation, reverse proxy and TLS management, and enough application knowledge to judge whether a Storage or Auth change breaks a client.
A retainer or fixed-scope handover can cover part of this load. DeployOpen plans, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and ongoing upgrades and support are available as retainers. A fixed-scope handover can define the upgrade runbook, the backup and restore test, the monitoring setup and the knowledge transfer to your staff. Ask for each item to be written into the scope with a named deliverable, and confirm which vendor-side support, if any, sits outside that scope. Any retainer should state which upgrades it includes, how security patches are handled, and who is accountable when a vendor release breaks your configuration.
Questions buyers ask before comparing costs
Is self-hosting Supabase actually cheaper than Firebase at every scale?
No, and the answer depends on which costs you count. Firebase bills by usage on the Blaze plan, so spend rises with Firestore reads and writes, Auth monthly active users, Storage, Functions and Hosting transfer. Self-hosting replaces those meters with fixed infrastructure plus people. For a small app with light traffic, the infrastructure line is often small, but the operating time can outweigh it. Model both sides at your expected peak and at your growth rate, and include backups, patching and on-call. Supabase's self-hosting guide lists minimum requirements of 4 GB RAM, 2 CPU cores and a 40 GB SSD, and recommends 8 GB RAM, 4 cores and 80 GB, so start your server model from those figures.
How long does a Firebase to self-hosted migration take, and what drives it?
The duration depends mostly on data volume, how many Firestore documents must be reshaped into Postgres tables, how many client SDK calls must be rewritten, and how many users must move without a password reset. Supabase documents scripts for Firestore data, Auth users and Storage files, so the data movement itself is scriptable, but the data-model rewrite and security rule translation are design work. Ask any implementation partner for a written timeline tied to a named scope. Pre-cutover testing of password hash imports is a common schedule risk.
Can our own team run the migration without outside help?
Often yes for a small, well-documented app, and less so when the data model or the security rules are complex. Supabase publishes migration scripts and Docker self-hosting documentation, so a team with Postgres and client SDK experience can follow them. The harder parts are the data-model redesign, moving Auth users with their scrypt parameters, and rebuilding access rules as Postgres row level security. If you lack that experience, a fixed-scope engagement with written deliverables can cover only the parts you choose. Confirm your team's readiness against the migration checklist before deciding.
What skills does the team need to operate self-hosted Supabase?
The operating team needs Linux and Docker Compose administration, Postgres backup and restore, TLS and reverse proxy setup, secrets handling, monitoring, and a plan for upgrades. Supabase's self-hosting docs warn against starting with the placeholder secrets in .env.example and provide scripts to generate secrets and the JWT key pair, so someone must own that process. Each Docker configuration release pins specific Auth, PostgREST and Realtime versions, and some releases require a database backup before updating. Budget for a named owner, and confirm the skill gaps before the build starts.
Is Supabase Cloud or Appwrite Cloud Pro a middle option?
Yes, a hosted tier can reduce operating work while keeping a migration off Firebase, but it changes the cost model. Supabase's pricing page and Appwrite's pricing page both list paid plans, and Appwrite's Pro plan starts at $25 per month with 2 TB bandwidth, 150 GB storage and 200K monthly active users per project. Those are the figures to compare against your Firebase bill at the same usage. Note that self-hosted Supabase lacks branching, managed backups and point-in-time recovery, which hosted plans include. Confirm the hosted region and data location requirements for your workload before choosing.
What should we request in a quote for a self-hosted backend migration?
Ask for a written scope that lists each Firebase service in use, such as Firestore, Auth, Storage, Functions and Hosting, and states which are migrated, rebuilt or retired. Request the server topology, the backup and restore approach, the upgrade process, and what is one-time versus recurring. Ask who patches the stack after handover and how security testing is scoped. Require the deliverables, acceptance tests for password hash imports, and the assumptions behind the timeline. Also ask what the quote excludes, such as client app rewrites or Firebase Extensions replacement.
Is PocketBase enough for a small app that outgrows Firebase's free tier?
It can be for a small app with one server and a single-region audience, but it has clear limits. PocketBase embeds SQLite, scales only vertically on a single server, and is self-hosted only with no paid company behind it. Its documentation says full backward compatibility is not guaranteed before v1.0.0 and that it is not recommended yet for production critical applications. The PocketBase FAQ also describes support as volunteer-based. Its MIT license and low infrastructure footprint keep direct costs low, so the decision rests on growth expectations and how much risk you accept in upgrades.
What to ask for in a fixed-scope quote
A written scope is what makes a Firebase versus self-hosted comparison reliable, because a quote follows from the scope and DeployOpen does not publish a price list. Ask for the scope to name each environment (production, staging and any test or cyber range copy) and whether each one must be built, migrated, or only documented. Data volumes should be stated per collection in Firestore and per table once you have modeled the Postgres schema, along with document counts, average document size, and the number of subcollections that will become foreign-keyed tables. Auth user counts should be split by sign-in method (email and password, Google, Apple, phone) and by whether the password hashes can be exported with their scrypt parameters, since that determines whether users move without resets. File volumes should cover object count, total size and the access rules that govern each bucket.
The scope should also name the backup and restore targets and the migration cut-over plan. Specify the recovery point you need, where backups are stored, and whether you expect a restore test to be run and evidenced before cutover. Ask how the team will handle a dual-run period, how writes are frozen or replicated during the switch, and what rollback looks like if the Postgres import or the auth import fails. Also confirm the Firebase Blaze plan usage you will still pay for during the overlap, since that cost sits outside any self-hosting quote. Finally, ask for the handover documentation and any retainer for upgrades: runbooks for patching the self-hosted stack, a list of upstream service versions you will need to track, and a stated cadence for reviewing security fixes. Any retainer should be priced separately from the one-time build, so you can compare the recurring cost with the Firebase bill you are replacing.
How DeployOpen scopes a fixed-price implementation
DeployOpen is a Chainscore Labs company that 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 cost review, we start from your current Blaze bills and the infrastructure you would run, then agree the work in writing before anything is built.
How we scope
- We inventory your Firestore, Auth, Storage, Functions and Hosting usage so the cost comparison reflects your actual workload.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ask the written scope to name the hosting target, the Supabase components in use, and which Firebase features are excluded.
How we build
- We size the self-hosted Supabase Docker deployment, storage, backup target and monitoring against the workload agreed in scope.
- We plan the one-time migration, covering Firestore data mapping, Auth user import and Storage file transfer, and test each step in a non-production environment.
- We test password hash compatibility and access rules before cutover, so security gaps are found before users are affected.
How we hand over
- You receive documentation of the deployed architecture, configuration, secret handling and backup and restore procedures.
- We document the operating tasks your team takes on, including upgrade steps and the one-way Storage migration checks in each release.
- Handover includes a written record of cost drivers, so your finance and platform teams can track recurring infrastructure spend.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the implementation.
- Retainers can cover patching the Docker configuration and its bundled upstream services as new releases ship.
- Ask any provider, DeployOpen included, to confirm who is paid for on-call response and which supported channels apply to your stack.
