When It's Time to Move Off Firebase, and How to Do It Safely

Every founder who chose Firebase for their MVP eventually reaches the same page. Analytics is broken because Firestore can't join. The bill has quietly tripled. And the last three features have been harder than they should have been. That's the moment this post exists for.

At Augere Labs we've migrated multiple SaaS products off Firebase. The good news: it's usually smoother than founders expect. The bad news: the teams that hit trouble almost always hit the same specific rocks.

The short answer on when to migrate

Migrate when you're building the second reporting dashboard, when your Firebase bill passes $2K/month, or when you're seriously considering a data warehouse just to run queries. Two of those three signals means the friction is now bigger than the migration effort.

Why Firebase eventually stops working for SaaS

You can't write the queries you need

Firestore is fantastic for "get me this document by ID." It's painful for "show me all workspaces with more than five active users where the plan is Pro and the last invoice failed." That kind of query is the bread and butter of any SaaS operator, and Firestore forces you into either denormalization or exporting to BigQuery, which is a whole other project.

Costs stop being predictable

Firestore charges per read, per write, and per document scanned. A single "show me the last 30 days of activity" screen can pull tens of thousands of reads for a mid-size customer. The billing chart looks fine until suddenly it doesn't.

Row-level security is DIY

Firestore has security rules, which are powerful but weird — a small DSL that gets increasingly hard to reason about as your access model matures. Postgres with RLS gives you the same guarantees in a language your team already knows. See our take on Supabase vs Firebase for the deeper comparison.

Vendor lock-in gets real

By year two, your app is talking to Firestore SDKs from every direction: web, mobile, functions. Migrating starts to feel like a rewrite. It isn't — but it does require planning.

The migration path we actually use

Phase 1 — Model in Postgres, don't cut over yet

Design the target schema in Postgres. Include everything you know is missing from Firestore: proper foreign keys, indexes on the columns you filter by, and RLS policies for tenant isolation. If you're going to Supabase or Neon, this is a good moment to consolidate auth and storage too.

Don't rush this step. Migrations that fail usually fail because someone tried to reproduce the Firestore shape one-to-one in Postgres. You'll normalize things. That's the point.

Phase 2 — Dual write from the app

Every write in your app goes to both Firestore and Postgres, in that order. Reads still come from Firestore. This phase catches schema bugs early — you'll see NULL constraint failures on the Postgres side within a day and fix them without disrupting users.

Keep dual writes running for at least a full billing cycle so you can catch edge-case flows that only fire monthly.

Phase 3 — Backfill historical data

Export the Firestore collections and load them into Postgres. This is where a lot of teams underestimate effort. Timestamps, nested arrays, and missing fields all need translation. Budget two to five days depending on collection size and messiness.

Verify with a row count check per collection and a sample of documents deep-compared. Don't just trust that the numbers match.

Phase 4 — Cut reads over gradually

Start with the least critical read paths. Move analytics first, then internal admin, then user-facing screens. Feature-flag each cutover so you can roll back per endpoint if something looks off in production.

Phase 5 — Stop writing to Firestore

Once all reads are on Postgres and dual writes have been stable for a couple of weeks, remove the Firestore writes. Keep the project alive as a cold backup for a month before decommissioning.

Mistakes teams make

Trying to preserve Firestore document shapes

Deeply nested documents don't translate cleanly to normalized tables. Some fields become JSONB columns, others become separate tables. Deciding which is where domain knowledge earns its keep. Don't outsource this decision to a script.

Skipping the dual-write phase

"We'll just do it over a weekend" is how six-week outages start. Dual writes cost a bit of complexity and buy you a safe rollback at every step.

Migrating auth in the same window

If you're on Firebase Auth, you can move the database first and keep Auth on Firebase for a while. Doing both at once means you're debugging two moving targets simultaneously — a bad idea when users are trying to log in.

Not planning for offline clients

Firestore has excellent offline support baked in. If your mobile app relies on it, you need a replacement plan — PowerSync, ElectricSQL, or a hand-rolled sync layer. Don't discover this on cutover day.

A real example

A B2B analytics product we worked with had grown to about 400 customers on Firebase. Their monthly bill had hit $4,300, and every new report request required a BigQuery export and a scheduled job. They were spending more engineering time on data plumbing than on the product.

We moved them to Postgres on Supabase over about six weeks. New feature velocity roughly doubled in the following quarter, and their database cost dropped to under $400/month. The interesting metric: their support-ticket volume on data issues also fell, because RLS eliminated a class of "wrong customer saw wrong data" bugs the security rules had been hiding.

Trade-offs to be honest about

Postgres won't give you Firestore's real-time listeners for free. Supabase Realtime and Neon's logical replication cover most cases, but if your app relies on hundreds of thousands of live subscriptions, expect to engineer that layer.

You'll also give up Firestore's offline-first defaults on mobile. If offline is a first-class requirement, factor in the sync tooling from the start.

Common misconceptions

"Firebase is cheaper for small apps." True on day one, less true by month twelve. The reads-per-screen model punishes usage growth in a way flat-fee Postgres hosting doesn't.

"We should rewrite the whole app when we migrate." No. Migrate the database, keep the app the same. Rewrite is a different project — bundling them roughly triples the risk.

"Postgres won't scale." It will scale further than most SaaS products ever need. Managed Postgres on Supabase, Neon, or RDS handles millions of users comfortably. Scaling myths from 2012 don't apply to 2026 hardware.

Frequently Asked Questions

How long does a Firebase to Postgres migration take?
Four to eight weeks for a mid-size SaaS, done carefully. Faster is possible; safer is usually better.

Should I use Supabase or plain Postgres?
Supabase if you want auth, storage, edge functions, and realtime bundled. Plain Postgres on Neon or RDS if you want just the database and prefer to compose the rest.

Do I need to migrate Firebase Auth too?
Not at the same time. Migrate the database first, then plan auth as a separate project once things are stable.

What about Firebase Storage?
Easiest to migrate last. Copy files with a background job to Supabase Storage or S3, update references, then switch reads. Users rarely notice.

Where to go next

If you're weighing the alternatives before you commit, read Supabase vs Firebase and Postgres vs MongoDB for AI SaaS. If AI features are pushing you toward Postgres specifically, choosing a vector database covers pgvector in depth.

Working with us

Firebase migrations are one of those projects where the ROI is real but the process needs experience. Our SaaS and web apps practice has done this for teams from ten customers to a few thousand — happy to talk through your specific situation.