Cost to migrate from Firebase to Supabase
Cost to migrate from Firebase to Supabase
Migrating from Firebase to Supabase in 2026 typically costs $8,000 to $60,000 in engineer-weeks for a real production app, plus a one-time platform overlap of $50 to $500 while both stacks run in parallel. The biggest cost drivers are how much custom Cloud Functions logic you have, whether Realtime Database is load-bearing, and how strict your Firestore security rules are.
The data move itself is the cheap part. The expensive parts: schema design, Auth user import with password rehash, Cloud Functions rewrite from Node to Deno, FCM replacement (Supabase has none), Realtime model swap, security rules to RLS, and gradual cutover.
This post breaks the migration into the seven sub-projects that drive the budget, prices each one in engineer-weeks at real 2026 rates, and walks through three concrete scenarios with total dollar figures.
What you actually pay for in a Firebase to Supabase migration
The Supabase docs make it look like three commands: firestore2json, json2supabase, done. The data move is maybe 10% of the real cost. The other 90% is work the official tooling doesn't touch:
- Schema design. Firestore is a denormalized document store. Supabase is Postgres with foreign keys and indexes. You redesign, not migrate.
- Auth migration. Firebase uses scrypt; Supabase uses bcrypt. Users either reset passwords or you rehash on first login.
- Cloud Functions rewrite. Firebase Functions run on Node in GCP. Supabase Edge Functions run on Deno. Every function needs a rewrite.
- FCM has no Supabase equivalent. Push notifications are your problem (OneSignal, Knock, or Expo).
- Realtime model swap. Firebase Realtime Database is a JSON tree with
.on()listeners. Supabase Realtime is Postgres logical replication plus Broadcast and Presence. - Security rules to RLS. No automated converter; you write SQL policies by hand.
- Gradual cutover. Dual-write, shadow read, feature flags, 30 to 60-day overlap.
Founders who scope only the data move end up three weeks behind. Scope all seven up front.
The 7 sub-migrations and what each actually involves
1. Firestore to Postgres schema design
The most underestimated job. You're not converting JSON to SQL, you're modeling the same domain in a different paradigm. Senior engineer, 40 to 120 hours, depending on collection count and denormalization. Output is schema.sql, an ER diagram, and a per-collection migration plan. Expect 5 to 20 Firestore collections to become 8 to 25 Postgres tables.
2. Firebase Auth to Supabase Auth
Use the official firestoreusers2json tool to export users. Firebase uses scrypt; Supabase uses bcrypt. Two paths:
- Force a password reset for everyone. Cheapest, but you lose 20 to 40% of inactive users.
- Rehash on first login. Verify against the scrypt hash once, store bcrypt, kill the old hash. About 20 to 40 hours of middleware work.
OAuth providers (Google, Apple, GitHub) get reconfigured with new redirect URIs; user records carry over by email match. Custom JWT claims map to user_metadata and app_metadata. Plan 30 to 80 hours including testing.
3. Cloud Functions to Edge Functions
Firebase Functions run on Node in GCP. Supabase Edge Functions run on Deno. Every function needs a rewrite, not a port. Typical cost is 4 to 12 hours per function for a mid-level engineer; variance comes from third-party SDKs that ship Node-only. A team with 15 functions is looking at 60 to 180 hours plus testing.
Useful pattern: keep simple webhook handlers on Firebase Functions for 30 to 60 days during cutover.
4. Realtime Database to Supabase Realtime
If you used Firestore for realtime: Supabase Realtime tails the Postgres write-ahead log. Wire it up in 20 to 40 hours.
If you used the legacy Firebase Realtime Database (JSON tree with .on('value') listeners): redesign required. Supabase Realtime has three channels (Postgres Changes, Broadcast, Presence) and none is a JSON tree. Plan 40 to 100 hours.
5. Firebase Storage to Supabase Storage
Both are S3-compatible. The official storage-copy tool handles bucket-to-bucket. Update SDK calls, regenerate signed URLs, update CDN config. Budget 20 to 40 hours including frontend signed-URL swaps.
6. Security rules to RLS policies
Firestore rules look like this:
match /orders/{orderId} {
allow read: if request.auth.uid == resource.data.userId;
}
The Postgres equivalent:
create policy "users read own orders"
on orders for select
using (auth.uid() = user_id);
Conceptually similar, syntactically different, no converter. A 200-line firestore.rules file is 20 to 60 hours to translate, test, and review. Spend senior hours here; this is the step teams botch.
7. FCM to a new push provider
Supabase has no push. You pick:
- OneSignal (free up to 10k subs, then $9/mo+). About 8 hours.
- Knock (~$0.05/notification, generous free tier, cross-channel). About 12 hours.
- Expo Push (free, only if you're on Expo). About 4 hours.
- Self-hosted FCM proxy. FCM still works as a standalone Google product; keep tokens, drop Firebase SDK. About 16 hours.
Most teams pick OneSignal. Plan 8 to 20 hours plus monthly fee.
Cost breakdown by migration component (engineer-weeks)
Translating those hour ranges into engineer-weeks and dollar figures at real 2026 rates. A 40-hour week is the baseline.
| Component | Hours | Engineer-weeks | Tier needed | Cost (Cadence) |
|---|---|---|---|---|
| Schema design | 40-120 | 1-3 | Senior | $1,500-$4,500 |
| Auth migration | 30-80 | 1-2 | Mid/Senior | $1,000-$3,000 |
| Cloud Functions rewrite | 60-180 | 1.5-4.5 | Mid | $1,500-$4,500 |
| Realtime DB swap | 20-100 | 0.5-2.5 | Senior | $750-$3,750 |
| Storage migration | 20-40 | 0.5-1 | Junior/Mid | $250-$1,000 |
| Security rules to RLS | 20-60 | 0.5-1.5 | Senior | $750-$2,250 |
| FCM replacement | 8-20 | 0.2-0.5 | Junior/Mid | $100-$500 |
| Gradual cutover + testing | 40-80 | 1-2 | Mid/Senior | $1,000-$3,000 |
| Total | 238-680 | 6-17 | Mixed | $6,850-$22,500 |
Anything past $22.5k is custom: legacy Firebase Realtime Database with deeply-nested listeners, 30+ Cloud Functions, or a complex multi-tenant rules system. Those projects land in the $30k to $60k zone.
Three real cost scenarios
Scenario A: 10k MAU side project, simple feature set
5 Firestore collections, 3 Cloud Functions, Firebase Auth with email + Google sign-in, no push notifications, no Realtime Database.
| Component | Hours | Tier | Cost |
|---|---|---|---|
| Schema design | 30 | Mid | $750 |
| Auth migration | 20 | Mid | $500 |
| 3 Cloud Functions | 18 | Mid | $450 |
| Storage | 10 | Junior | $125 |
| Security rules → RLS | 16 | Senior | $600 |
| Cutover + testing | 24 | Mid | $600 |
| Total | 118 hrs | $3,025 |
Booked as 1 mid engineer for 3 weeks on Cadence: $3,000 flat. Or one focused senior week ($1,500) plus a polishing mid week ($1,000) at $2,500.
Scenario B: 100k MAU production app, real complexity
12 collections, 10 Cloud Functions, Firebase Auth with three OAuth providers, FCM push, Firestore-based realtime feed, 300-line security rules file.
| Component | Hours | Tier | Cost |
|---|---|---|---|
| Schema design | 80 | Senior | $3,000 |
| Auth migration (rehash on login) | 50 | Senior | $1,875 |
| 10 Cloud Functions | 90 | Mid | $2,250 |
| Realtime feed (Postgres Changes) | 40 | Senior | $1,500 |
| Storage | 30 | Mid | $750 |
| Security rules → RLS | 40 | Senior | $1,500 |
| FCM → OneSignal | 14 | Mid | $350 |
| Cutover + testing | 60 | Senior | $2,250 |
| Total | 404 hrs | $13,475 |
Booked as 1 senior engineer + 1 mid engineer for 5 weeks: $12,500. Realistic with a 1-week buffer at $14,500.
Scenario C: 500k MAU multi-tenant SaaS
30 collections, 25 Cloud Functions, custom JWT claims, Firebase Realtime Database for live cursors, complex tenant-isolation security rules, two iOS/Android apps with FCM.
| Component | Hours | Tier | Cost |
|---|---|---|---|
| Schema design + ER review | 120 | Lead | $6,000 |
| Auth + multi-tenant claims | 80 | Senior | $3,000 |
| 25 Cloud Functions | 200 | Mid | $5,000 |
| Realtime DB → Broadcast/Presence | 100 | Senior | $3,750 |
| Storage | 40 | Mid | $1,000 |
| Security rules → RLS (tenant) | 60 | Lead | $3,000 |
| FCM → OneSignal (iOS+Android) | 20 | Mid | $500 |
| Cutover + testing + monitoring | 100 | Lead | $5,000 |
| Total | 720 hrs | $27,250 |
Booked as 1 lead + 1 senior + 1 mid engineer for 6 weeks parallel: $27,000. Real teams add 30% buffer for production surprises, landing at $35k to $52k all-in.
Approach comparison: who should do the migration
| Approach | Cost | Timeline | Pros | Cons |
|---|---|---|---|---|
| DIY (founder + AI) | $0 cash, 6-12 wks calendar | 6-12 weeks | Cheapest, deepest learning | Slowest, highest cutover risk |
| US full-time hire | $30k-$60k | 3-5 wks plus 6 wks to hire | Long-term capacity | Overkill for a one-time project |
| Dev agency | $40k-$120k | 4-8 weeks | Project management included | Highest cost, slowest start |
| Freelancer (Upwork) | $5k-$25k | 4-10 weeks | Cheapest paid option | Vetting risk, no easy replacement |
| Toptal | $15k-$50k | 1-2 wks to start, 3-6 wks build | Vetted senior pool | Monthly billing, no AI-native baseline |
| Cadence | $500-$2,000/wk | 48-hour trial then ship | Every engineer AI-native, weekly billing, replace any week | Less suited to enterprise procurement |
Honest take: for the 10k MAU scenario, a full-time hire is silly and an agency is wasteful. DIY with Cursor and Claude Code is real if you have three weekends. Booking wins past about 80 hours of scope, which is most production migrations.
Every engineer on Cadence is AI-native by default, vetted on Cursor, Claude Code, and Copilot fluency in a voice interview. A schema redesign that takes a week by hand becomes a day with Claude drafting schema.sql. Same speed-up applies to RLS policies and Cloud Function rewrites. For a parallel breakdown, see our cost-to-migrate-from-Heroku-to-AWS guide.
Gradual cutover patterns that prevent disasters
Big-bang cutovers fail. The pattern that works:
- Week 1-2: dual-write. Every Firestore write also writes to Postgres. Reads stay on Firestore. Zero user impact.
- Week 3: shadow read. Read from Postgres, compare to Firestore, log diffs. Firestore stays source of truth.
- Week 4: feature-flag auth. New signups go to Supabase Auth. Returning users hit rehash middleware.
- Week 5: cutover reads. Flip read source to Postgres at 10%, 50%, 100%. Keep Firestore writes as backup.
- Week 6: turn off Firestore writes. You're committed.
- Week 7-8: keep Firebase alive but unused. Cheap insurance. Delete after 30 clean days.
Overlap costs $50 to $500 in extra platform fees depending on Blaze usage. The price of not losing user data.
When migration costs more than staying on Firebase
Don't migrate if:
- Firebase bill is under $300/month. Won't pay back in two years.
- You have fewer than 5 Cloud Functions and no Realtime Database.
- Founder-only team and shipping features is the bottleneck. A 6-week migration is 6 weeks not shipping product.
- You need on-device offline sync with conflict resolution. Firestore handles this better today.
Migrate if:
- Firebase bill is $500/month or higher and growing.
- You need Postgres-native queries (joins, window functions, JSONB indexing).
- You want vendor independence or self-hosting.
- You hit Firestore hard limits (1MB document size, no
ORqueries without composite indexes).
For teams crossing $500/month, payback is 6 to 14 months. Under $300/month, it's a hobby project.
The fastest path from Firebase to Supabase
Three steps:
- Spend a week on the schema. Senior engineer, 40 hours, one deliverable:
schema.sqlplus per-collection migration plan. No application code until reviewed. Bad schemas haunt you for years. - Build the dual-write layer. Your safety net. Every other step is reversible with it; without it, every step is a coin flip.
- Easiest service first, hardest last. Storage and Auth are easy. Save security-rules and Cloud Functions for last so you've practiced patterns on low-risk surfaces.
If you don't have an engineer who has done this before, book one for week one. A senior on Cadence ($1,500/week) covers schema design and dual-write architecture; a mid ($1,000/week) handles bulk rewrites in weeks 2 to 5. Total spend lands $7,000 to $15,000 for most production apps, vs $40,000 for the agency version.
For parallel cost frameworks, see our deep dive on cost to build a recruiting platform and cost to add RAG to a SaaS app.
Need someone who has done this migration before? Book a senior engineer on Cadence at $1,500/week with a 48-hour free trial. Replace any week, weekly billing, no notice. Most production migrations finish in 4 to 6 weeks.
FAQ
How long does a Firebase to Supabase migration take?
Two to twelve weeks of calendar time depending on app complexity. A 10k MAU side project is two to three weeks of focused work. A 100k MAU production app is four to six weeks with one senior and one mid engineer. A multi-tenant SaaS is eight to twelve weeks with a three-person team running in parallel.
Can I migrate from Firebase to Supabase without downtime?
Yes, using dual-write and gradual cutover. Run both backends in parallel for 30 to 60 days, migrate users at login (rehash the scrypt password to bcrypt during first sign-in), and flip a feature flag per user once verified. Done right, no user notices the migration.
What does Supabase not replace from Firebase?
Firebase Cloud Messaging (FCM) for push notifications has no Supabase equivalent. You will need OneSignal, Knock, Expo Push, or a self-hosted FCM proxy. Crashlytics, A/B Testing, Remote Config, and Firebase Performance Monitoring also lack direct replacements; teams typically pick Sentry, Statsig, and Sentry Performance respectively.
Is it worth migrating from Firebase to Supabase?
Only if your monthly Firebase bill is over about $300 to $500, you need Postgres-native queries, or you want to self-host. Below that threshold the migration cost outweighs the savings for one to two years. Above it, payback is typically 6 to 14 months.
How much does Supabase cost compared to Firebase at scale?
At 100k MAU, Supabase Pro runs about $25 base plus usage (typically $50 to $200/month all-in). Firebase Blaze at the same scale frequently lands at $400 to $1,500/month depending on Firestore reads and Cloud Functions invocations. The Postgres-based pricing model is more predictable, which is a real reason teams move beyond the dollar savings.