How far can you scale with Firebase before a migration becomes necessary?

Apps8 min read

Firebase scales further than many people think. Apps with millions of users run on Firebase (Duolingo, Alibaba, parts of The New York Times). Practical limits are rarely in capacity, more often in: query complexity (no JOINs), costs at high read volumes, and region-specific compliance. For B2C apps up to 5M MAU, Firebase is fine; above that, a hybrid approach (Firebase + BigQuery + custom services) becomes common. For B2B SaaS, it scales up to tens of thousands of tenants.

The Technical Limits

Firebase services have hard limits, but they are usually high:

  • Firestore — 1 million concurrent connections per database, 10,000 writes/sec per database (auto-scaling), 1MB per document. Practically unlimited storage.
  • Authentication — no hard limit on the number of users; supports up to billions.
  • Cloud Functions — 1,000 concurrent executions/region default (scalable), 9 minutes max execution time, 8GB memory max.
  • Storage — 5 PB per bucket. In practice, never reached.
  • Hosting — 250GB transfer/month on Blaze plan (additional payment), CDN across 100+ POPs.

For 99% of apps, these limits are not a showstopper. Bottlenecks arise elsewhere.

Where You'll Encounter Limitations in Practice

  • 1. Complex queries. Firestore does not support JOINs and has limitations on compound queries (combinations of WHERE clauses). For analytics-like queries, you need to denormalize or export to BigQuery.
  • 2. Read-volume costs. Firestore charges per document read. For apps with many listings (a table with 1,000 items = 1,000 reads), costs can quickly add up. Caching becomes crucial.
  • 3. Single-region writes. Firestore is multi-region for reads (replicas), but writes go to a single primary region. For global apps with many writes: latency issue.
  • 4. Functions cold-start. Cloud Functions have a 1-5 second cold-start when idle. For latency-critical APIs: either keep warm or switch to Cloud Run.
  • 5. Vendor lock-in. Not a technical limit but a strategic one: migrating away from Firebase is expensive, so check your 3-year plan beforehand.

How Far Can You Really Go? Practical Cases

  • B2C consumer app, <1M MAU: Firebase is comfortable. Costs are manageable (€200-€2,000/month).
  • B2C app, 1M-10M MAU: Firebase works, provided it's well-designed. Costs €2,000-€20,000/month. Caching and query optimization are crucial.
  • B2C app, 10M+ MAU: Often hybrid. Firebase for auth + Firestore for user data, but analytics and feeds via BigQuery/Pub/Sub.
  • B2B SaaS, <1,000 tenants: Perfectly fine on Firebase. Multi-tenancy via subcollections or a tenant-ID field.
  • B2B SaaS, 10,000+ tenants: Still works, but necessitates architectural choices. Enterprise features (audit logs, isolation) are built on top.
  • Regulated/compliance-heavy (healthcare, banking): Here, Azure or AWS are often preferred for compliance reasons, not technical ones.

Signals That You Should Migrate (or Hybridize)

  • 1. Your Firebase costs exceed >€10,000/month. At that scale, a hybrid architecture quickly pays for itself.
  • 2. You perform analytics on your production database. Bad idea — export to BigQuery, do analysis there.
  • 3. You need ACID transactions across more than 5 documents. Firestore transactions are limited. A PostgreSQL database elsewhere can be more robust.
  • 4. You have strict compliance requirements. Some sectors (healthcare, finance, defense) simply do not accept Google Cloud without their own sovereignty cloud.
  • 5. Your team needs to make scaling engineering choices that Firebase does not allow. Custom caching, custom sharding, etc.

Common Mistakes

  • Giving up on Firebase "because of scalability". Often a misunderstanding. First, investigate whether your bottleneck is truly scale, or a design choice.
  • Migrating as a panic-move. If your costs are rising, optimize first (denormalize reads, cache aggregates, rethink your read patterns). Migration costs more than optimization.
  • Ignoring that your app is running perfectly fine. Sometimes an expensive Firebase bill is cheaper than a rebuild to AWS. Do the math.
  • Building custom sharding solutions without real necessity. Premature optimization.
  • No monitoring dashboards. Without visibility into reads/writes per collection, you won't know where bottlenecks are.

Frequently Asked Questions

Which large apps run on Firebase?

Duolingo, Alibaba, NPR, The New York Times (sub-apps), Halfbrick (Fruit Ninja), Twitch (chat system), and thousands of SaaS tools. Scale is not an issue, provided it's well-designed.

Can I combine Firebase with PostgreSQL?

Yes. Many apps use Firebase for auth + real-time UX and a separate PostgreSQL (via Supabase, Neon, or self-hosted) for complex relational data. The combination works well.

How expensive does Firebase really get with 1M users?

Highly dependent on read patterns. A typical consumer app with 1M MAU and an average of 10 sessions/month: expect €3,000-€8,000/month. For read-heavy use cases (feeds, listings): €8,000-€20,000/month without optimization.

Is Firestore slow with large datasets?

No, Firestore queries remain fast regardless of collection size (logarithmic scaling). What becomes slow: reading thousands of documents in a single query. Therefore: always paginate, cache aggregates.

Can I easily migrate from Firebase to Supabase?

Not easily. Firestore is NoSQL, Supabase is PostgreSQL. Migration requires schema design, data transformation scripts, and application rewrite for queries. Expect 30-50% of the original build time.

Does Firebase have an SLA?

On the Blaze plan: 99.95% uptime SLA for Firestore and Cloud Functions. Authentication: 99.9%. Sufficient for SMEs; sometimes too low for mission-critical financial apps — there, you choose AWS or Azure with a dedicated tier.

Ready to Get Started?

Read about our approach to building a Firebase app, or schedule a brief introductory meeting — we'll provide a no-obligation review and an honest estimate of scope, costs, and lead time.

Back to Journal →
Chat