Firebase alternatives: where to go and how to migrate without breaking things
Nine options, one per reason to leave, plus a nine-step migration plan.
The short answer: Supabase if you want real SQL and a spend cap that is on by default; Appwrite if you want the closest thing to Firebase and to keep your users' passwords; Convex if real-time sync is the core of your app; PocketBase for a small project on one cheap server; AWS Amplify if your team already lives on AWS; Xano if you build without writing a backend. And if NoSQL is your only problem, Firebase Data Connect gives you Postgres without leaving Google. One thing before you choose: the official Firestore export requires the Blaze plan and bills one read per document. We compared all nine options and checked their 2026 pricing.
The ranking is editorial: a sponsored spot is always labeled on its card, and no affiliate link changes a score.
Why teams leave Firebase, and why it takes time
Firebase is still the fastest way to ship an app: auth, database, storage and hosting in a few clicks. People leave later, once the app grows. Six reasons keep coming up, all checked in 2026.
Bill shock with no brake on the database
Firestore charges per read, write and delete: from $0.03 per 100,000 reads, $0.09 per 100,000 writes and $0.01 per 100,000 deletes in the default region, a bit more in Europe. The catch: budget alerts only notify you, they never stop anything. Automatic caps exist only for Cloud Functions, App Hosting, AI Logic and Extensions. For Firestore and Storage you have to write your own function that disables billing. One team got a bill of about $72,000 within hours from a single runaway loop, with its budget set at $7.
Queries hit a wall fast
No joins. An in filter takes at most 30 values, not-in at most 10, and you can't combine not-in with !=. No full-text search either: you bolt on Algolia or Typesense. Anything the database can't filter gets filtered in your client, and every document you read for nothing is a read you pay for. One developer who left wrote that he ended up denormalizing everything, down to username uniqueness.
One admin dashboard can triple the bill
Per-read pricing punishes screens that show lots of data. A detailed migration write-up describes one project going from $47 to $380 a month on Firebase because of a single admin dashboard re-reading whole collections. The code hadn't changed; the user base had.
Lock-in at every layer
Your data is denormalized documents, your security rules use their own language, and the Firebase SDK is called all over your code. Leaving isn't copying a database: it's redesigning the data model, rewriting access rules and replacing every call. The more mature the app, the bigger the exit cost, wherever you go.
A paid, gated exit
The official Firestore export requires Blaze (a card on file) and a Cloud Storage bucket. Every exported document counts as a billed read that the Firebase console doesn't show you. Passwords use a modified scrypt with per-project parameters: without them, every user has to reset.
The free tier is thinner than it looks
Spark has no Cloud Functions and no phone auth. On Blaze, new Storage buckets only get the no-cost quota in three US regions (us-central1, us-west1, us-east1): a bucket in Europe is billed from the first gigabyte.
You're leaving because… go to…
The right Firebase alternative depends on what's pushing you out. Usually one line fits. Each card links to the detailed profile below.
Full Postgres: joins, full-text search, unique constraints.
You want to change as little code as possibleAppwriteSame building blocks as Firebase and a built-in migration that keeps password hashes.
Real-time sync is your whole appConvexA reactive database in TypeScript: screens update themselves.
You're scared of the next billSupabase or PocketBaseSpend cap on by default on Supabase Pro, flat server cost with PocketBase.
You're all-in on AWSAWS AmplifyCognito, AppSync, DynamoDB and Lambda behind one tool.
Only NoSQL bothers you, not GoogleFirebase Data ConnectPostgres on Cloud SQL, still inside the Firebase console.
Firebase alternatives, one by one
For each option: why move there, who it's for, its limit, how to migrate from Firebase, and what it costs. Prices are what vendors list in 2026, in US dollars, before tax.
Supabase: real SQL with a spend cap
Our default pickWhy move to Supabase. It's the most recommended Firebase alternative, for good reason: the same building blocks (auth, database, file storage, functions, real-time) on top of Postgres. You get joins, full-text search and unique constraints, everything Firestore made you hack around. It's open source and self-hostable, and on Pro a spend cap is on by default. We rate it 4.3 out of 5 in our full Supabase review.
Who it's for. Teams with relational data (users, orders, subscriptions) who still want a ready-made backend.
Who it's not for. Offline-first apps: Firestore's local cache has no direct equivalent. One write-up on migrating fourteen projects mentions three weeks to rebuild a local layer.
Its limit. Free projects pause after a week of inactivity, and you get two active projects. Compute is billed per project, and edge functions run on Deno, so your Node functions need a rewrite. Database connections are limited: use the connection pooler.
How to migrate. Supabase ships official tools: firestore2json then json2supabase turn each collection into a table (nested fields go to jsonb). For users, firestoreusers2json then import_users; write down your project's four hash parameters. A middleware can verify the old password on first sign-in to avoid a mass reset.
Pricing. Free: 50,000 MAU, 500 MB database, 1 GB files, 5 GB egress. Pro from $25 a month per organization, including $10 of compute: 100,000 MAU then $0.00325 each, 8 GB disk then $0.125/GB, 100 GB files, 250 GB egress.
- Free
- 50,000 MAU, 500 MB
- Paid
- Pro from $25/mo
- Best for
- relational data
- Limit
- no native offline
Appwrite: closest to Firebase, password hashes included
Smoothest migrationWhy move to Appwrite. Appwrite mirrors Firebase almost block for block: auth, a document database, storage, functions, real-time. Your document model can stay close to what it is today. Its built-in migration imports users with their passwords, so nobody notices. It's open source and runs on your own server with Docker.
Who it's for. Teams that want off Google without redesigning their data, and teams that want to self-host.
Who it's not for. Apps on the legacy Realtime Database: the migration tool doesn't support it.
Its limit. The tool only brings over top-level Firestore documents: subcollections are on you. Functions need a rewrite, and Google or Apple sign-in users have to log in again once. On Free, a project that hits a limit freezes and the console goes read-only.
How to migrate. In the console, open Migrations, pick Firebase, paste a service account key, tick users, database and files. Run it on a test project first and compare document counts.
Pricing. A free plan, then a usage-based Pro plan where you set a budget cap; Appwrite emails you at 75% and 100% of limits. Dedicated databases start at $10 a month, and $10 of database compute credit is included every month. Self-hosted, you only pay for the server.
- Free
- yes, freezes at the limit
- Paid
- Pro with budget cap
- Best for
- keeping passwords
- Limit
- no subcollections
Convex: when your app lives in real time
Best real-timeWhy move to Convex. What developers love about Firestore is the screen that updates itself when data changes. Convex takes that further: a reactive database where queries and mutations are TypeScript functions and every subscribed client gets the changes. You keep the Firebase feel, typed end to end.
Who it's for. TypeScript teams building collaborative apps, shared boards, chat, games.
Who it's not for. Teams that want standard SQL and any BI tool plugged into their database.
Its limit. All your data-access code gets rewritten: nothing converts Firebase calls. Professional is priced per developer, which adds up on a ten-person team. Self-hosting works under a license that only becomes Apache 2.0 after two years.
How to migrate. Export collections to JSON, write your schema in TypeScript, import, then swap Firestore listeners for Convex queries screen by screen while Firebase stays read-only.
Pricing. Free, usage-based: 1M function calls then $2.20 per million, 0.5 GB database then $0.22/GB. Professional at $25 per developer per month with 25M calls and 50 GB.
- Free
- 1M function calls
- Paid
- $25/developer/mo
- Best for
- collaborative apps
- Limit
- full rewrite
PocketBase: one binary, one cheap server
CheapestWhy move to PocketBase. PocketBase is a single executable: SQLite database, auth, files, real-time and an admin UI. Drop it on a small VPS and you're done. The software is free and open source; your only cost is a flat-rate server. No per-read billing: the most radical cure for bill anxiety.
Who it's for. Indie hackers, internal tools, prototypes and modest apps.
Who it's not for. Apps that must scale across many servers, or teams that don't want to run a server.
Its limit. It only scales vertically: one machine, made bigger. It's still v0.x and the maintainer warns that backward compatibility isn't guaranteed, so read the changelog before each upgrade. Backups, security and uptime are yours.
How to migrate. No official tool: export Firestore to JSON and push records through the PocketBase API with a script. Users get recreated and set a new password.
Pricing. Free. The maintainer claims 10,000+ real-time connections on a $4 a month VPS.
- Free
- the whole thing
- Paid
- your server only
- Best for
- small projects, fixed budget
- Limit
- single server, v0.x
Nhost: Postgres and GraphQL out of the box
For GraphQL teamsWhy move to Nhost. Nhost pairs Postgres with Hasura, which generates a GraphQL API from your tables, plus auth and storage. You go relational without writing an API, on open-source parts.
Who it's for. Front-end teams already on GraphQL who want SQL without managing servers.
Who it's not for. Teams new to GraphQL, and companies that must pick a hosting region: the pricing page doesn't list them.
Its limit. Free is one project that pauses after a week of inactivity, and the community is smaller than Supabase's.
How to migrate. Same path as Supabase: export Firestore to JSON, remodel into tables, load into Postgres, recreate users.
Pricing. Starter free: one project, 1 GB database, 1 GB storage, 5 GB egress. Pro from $25 a month with $15 of compute, 10 GB database, 50 GB storage, 50 GB egress and backups.
- Free
- 1 project, 1 GB
- Paid
- Pro from $25/mo
- Best for
- GraphQL teams
- Limit
- regions not listed
AWS Amplify: stay with a hyperscaler, just not Google
For AWS shopsWhy move to Amplify. Amplify wraps AWS services (Cognito for users, AppSync, DynamoDB, Lambda, S3) behind one toolchain. If your company already has an AWS account, your data joins the rest of your infrastructure and contracts.
Who it's for. Teams that know AWS and want one vendor.
Who it's not for. Anyone fleeing usage-based billing: DynamoDB and Lambda work the same way. Read our guide to leaving AWS before you commit.
Its limit. The bill reads service by service, and the learning curve is steeper than Firebase.
How to migrate. DynamoDB is NoSQL too, so a document model maps over more easily than to SQL. Users and files follow the same steps as elsewhere.
Pricing. Hosting is free for 12 months (1,000 build minutes, 5 GB stored, 15 GB served per month), then $0.01 per build minute, $0.023/GB stored and $0.15/GB served. The backend is billed separately.
- Free
- 12 months of hosting
- Paid
- usage, per service
- Best for
- teams already on AWS
- Limit
- fragmented bill
Back4App: Parse Server at a flat price
Flat price per appWhy move to Back4App. Back4App hosts Parse Server, an open-source backend on MongoDB, so it's a document database like Firestore. Plans are a flat price per app: you know the bill before month end.
Who it's for. Small mobile apps that want a predictable budget without leaving NoSQL.
Who it's not for. Fast-growing projects: the jump between plans is big.
Its limit. Free is tight (25,000 requests a month, 250 MB), and going from $15 to the next plan at $80 hurts. Since Parse is open source, you can still move to another host later.
How to migrate. Export to JSON, adapt fields, import collection by collection, recreate users.
Pricing. Free: 25,000 requests a month, 250 MB, 1 GB transfer, 1 GB files. MVP at $15 per app per month billed yearly, Pay as you go at $80, Dedicated at $400.
- Free
- 25,000 requests/mo
- Paid
- MVP $15/mo (yearly)
- Best for
- predictable budget
- Limit
- $15 to $80 jump
Xano: a no-code backend
For no-code buildersWhy move to Xano. If your Firebase app is built in a visual tool like FlutterFlow and you don't write servers, Xano gives you a relational database and APIs assembled visually. We rate it 4.1 out of 5 in our Xano review, and FlutterFlow vs Xano explains how the two fit together.
Who it's for. No-code builders whose app already makes money, or soon will.
Who it's not for. Side projects on a tight budget.
Its limit. Nothing sits between free and $85 a month, and you still depend on one vendor.
How to migrate. Export collections to JSON or CSV, recreate tables in Xano, import, rewire your front end to its APIs, recreate users.
Pricing. A free plan for prototypes, then $85 a month billed yearly ($99 monthly).
- Free
- prototype
- Paid
- $85/mo
- Best for
- no-code apps
- Limit
- nothing between $0 and $85
Firebase Data Connect: stay, but go SQL
Don't leaveWhy consider it. If NoSQL is your only complaint, you don't have to leave. Data Connect attaches a Postgres database (on Cloud SQL) to your Firebase project, and you keep auth, hosting and the console you know. It also shows up under the name SQL Connect.
Who it's for. Teams happy with Firebase outside the database who want joins without a full migration.
Who it's not for. Anyone who wants off Google.
Its limit. Lock-in stays, and Cloud SQL adds a fixed monthly cost even when nobody uses the app.
How to migrate. Firestore and Data Connect live side by side: move one collection at a time.
Pricing. Three-month free trial for a Spark project, then Cloud SQL from about $9.37 a month; 250,000 operations a month included.
- Free
- 3-month trial
- Paid
- Cloud SQL from ~$9.37/mo
- Best for
- SQL without migrating
- Limit
- still on Google
Firebase and 9 alternatives side by side
Our default: Supabase for relational data, Appwrite to change the least code. Left: the free plan. Right: the first paid price and how you migrate.
| Free plan | First paid tier and migration | |
|---|---|---|
| FirebaseWhere you start | Spark: 50,000 reads and 20,000 writes a day, 1 GiB, no Functions | Blaze, pay as you go; auth free up to 50,000 MAU, then $0.0055 each |
| SupabaseSQL, spend cap | 50,000 MAU, 500 MB, pauses after a week | Pro from $25/mo; official Firestore and user import tools |
| AppwriteClosest match | Freezes at the limit | Usage-based Pro with budget cap; built-in migration keeps passwords |
| ConvexReal-time | 1M calls, 0.5 GB | $25 per developer/mo; code rewrite |
| PocketBaseSingle server | Free software | Server cost; scripted import |
| NhostGraphQL | 1 project, 1 GB database | Pro from $25/mo; import into tables |
| AWS AmplifyAWS ecosystem | 12 months of free hosting | Usage-based, backend billed apart; DynamoDB stays NoSQL |
| Back4AppFlat price | 25,000 requests/mo, 250 MB | MVP $15/mo billed yearly; import per collection |
| XanoNo-code | Prototype | $85/mo billed yearly; CSV or JSON import |
| Data ConnectStay on Google | 3-month trial | Cloud SQL from about $9.37/mo; runs next to Firestore |
Entry prices before tax, in US dollars, subject to change. Always check against your real user and read volumes.
Migrating off Firebase in nine steps
Order matters. Each step protects something: your data, your users, your files, or your app in production.
Inventory everything that runs
Day 1List collections and subcollections, security rules, every Cloud Function and its trigger, auth providers (email, Google, Apple, phone), Storage buckets and installed Extensions. Note volumes too: documents per collection and total file size. That sheet is both your estimate and your cutover checklist.
- Time
- half a day
- Risk if rushed
- a forgotten function
Export Firestore knowing what it costs
PaidThe managed export needs Blaze and a Cloud Storage bucket, and each exported document is a billed read the console won't show. One million documents is about $0.30 of reads at the default rate: cheap, but know it, especially if you export many times during trial runs. The alternative is an Admin SDK script such as firestore2json that writes each collection to JSON.
- Requires
- Blaze plan
- Cost
- one read per document
Remodel the data for the destination
The heavy liftingFor SQL targets (Supabase, Nhost, Xano), each collection becomes a table and nested arrays and subcollections become related tables. It's the moment to drop the duplicates denormalization forced on you. For Appwrite or Back4App, the document model can stay close, but subcollections need flattening.
- Time
- days to weeks
- Tip
- keep Firestore IDs
Export users with their hash parameters
CriticalRun firebase auth:export users.json with the CLI, not the Admin SDK: an SDK export gives you hashes nobody can verify. Then in Authentication, Users, the three-dot menu, Password hash parameters, copy the four values: signer key, salt separator, rounds, memory cost. Without them, no destination can check old passwords.
- Format
- JSON or CSV
- Write down
- 4 scrypt parameters
Import users without forcing a reset
User experienceAppwrite reads Google's format directly. On Supabase, use its scripts or a layer that checks the old password on first sign-in and re-hashes it. If your target can't, prepare a clear reset email: in one migration write-up, about 70% of users had to reset in the first week.
- Without parameters
- mass reset
- Easiest
- Appwrite
Warn your Google and Apple sign-in users
CommunicationSocial accounts carry no password. Depending on the target, those users sign in again once. Configure the same providers with the same redirect URLs, and announce it in the app before cutover.
- Effect
- one re-login
- Plan
- in-app notice
Copy files and rewrite every URL
Classic trapCopying files is easy. The trap is their URLs: they live in your documents, often inside rich text. Search every string containing your Firebase bucket name, HTML fields included, and replace them. A detailed write-up lists exactly these forgotten URLs in editorial content among its migration surprises.
- Search for
- your bucket domain
- Risk
- broken images
Rewrite functions and security rules
CodeEach Cloud Function needs porting: to Deno on Supabase, to Appwrite's function format, to TypeScript functions on Convex. Check Node dependencies one by one. Firebase security rules become row-level security policies in Postgres or permissions in Appwrite: rewrite them and test with an account that has no rights.
- Check
- Node dependencies
- Test
- unprivileged account
Cut over gradually, keep Firebase read-only
SafetyMove one screen or a small share of users first. Keep Firebase readable while you compare document and user counts. If your app relied on offline mode, test the destination's behavior before the full switch. Only turn off Firebase billing once everything checks out.
- Time
- one to two weeks
- Before closing
- compare counts
Is your tool missing from this page? Email us: hello@hackceleration.com
What makes a Firebase migration fail
The same mistakes show up again and again in write-ups from people who left. None is a deep technical mystery: they're oversights, and each costs more than avoiding it would have.
Exporting users with the wrong tool
An Admin SDK export gives you password hashes nobody can read. Use the CLI and grab the hash parameters the same day.
Assuming the export is free
It needs Blaze and bills a read per document. Trivial on a small database, a surprise if you export tens of millions of documents several times while testing.
Forgetting offline mode
Firestore keeps a local copy and syncs when the network returns. Supabase has no direct equivalent: if your users work on the go, budget a local layer and the time to build it.
Leaving Firebase Storage URLs behind
They survive in rich text, profiles and notifications. The day you delete the Firebase project, they all break at once.
Underestimating database connections
Firestore has no visible connection limit; Postgres does. Functions that open a connection per call saturate it fast: use the pooler from day one.
Shutting Firebase down too early
Keep it readable until document, user and file counts match. To compare more options, see Supabase alternatives, Xano alternatives and our ranking of no-code app builders.
- Collections, rules, functions, auth providers and Extensions inventoried
- Export cost estimated (one read per document)
- Data exported and remodeled for the target
- Users exported with the CLI, four hash parameters saved
- Passwords imported or reset email ready
- Google and Apple users warned
- Files copied and every URL rewritten
- Functions and security rules rewritten and checked
- Gradual cutover, Firebase kept read-only until verified
Firebase alternative FAQ
What is the best alternative to Firebase?
Supabase, for most apps: same building blocks, on Postgres, with a spend cap on by default on Pro. Appwrite wins if you want to keep a document model and your users' passwords with little effort. Our Supabase review covers its limits.
Is there a free Firebase alternative?
Yes. PocketBase is completely free; you only pay for a server. Supabase's free plan covers 50,000 MAU and a 500 MB database, but pauses projects after a week of inactivity and allows two active projects.
Is there an open-source Firebase alternative I can self-host?
Supabase, Appwrite and PocketBase are open source and self-hostable. Convex can be self-hosted too, under a license that becomes Apache 2.0 after two years. Budget the upkeep: upgrades, backups and security become your job.
How do I avoid a surprise Firebase bill if I stay?
Budget alerts don't stop anything. Automatic caps exist for Cloud Functions, App Hosting, AI Logic and Extensions; for Firestore and Storage you need a function that disables billing when the budget is reached. Also watch screens that re-read whole collections: they drive reads up.
How much does Firebase Auth cost past 50,000 users?
Above 50,000 monthly active users, email and social sign-in move to Identity Platform pricing: $0.0055 per user up to 100,000, then $0.0046 up to one million. At 80,000 MAU that's about $165 a month. Supabase Pro includes 100,000 MAU in its $25.
Can I keep user passwords when leaving Firebase?
Yes, if you export users with the CLI and save the project's four hash parameters. Appwrite reads them directly; Supabase uses its scripts or a check on first sign-in. Without the parameters, everyone resets.
Supabase or Appwrite to replace Firebase?
Supabase if your data is relational and you want SQL; Appwrite if you want to change the least code and keep documents. Supabase has the bigger community; Appwrite has the most direct Firebase migration, but it skips subcollections.
Which Firebase alternative has the best real-time?
Convex, if real-time is the core of your app: every query is reactive by default. Supabase and Appwrite both offer real-time subscriptions too, which is enough for notifications or live counters.
Get the next migration guide in your inbox
One tool to leave, one destination, one migration plan. Nothing else.
