Hoe ver kom je met Firebase voordat je moet overstappen?

Firebase schaalt verder dan veel mensen denken. Apps met miljoenen gebruikers draaien op Firebase (Duolingo, Alibaba, The New York Times-onderdelen). Praktische limieten zitten zelden in capaciteit, vaker in: query-complexiteit (geen JOINs), kosten bij hoge read-volumes, en regio-specifieke compliance. Voor B2C-apps tot 5M MAU is Firebase prima; daarboven wordt een hybride aanpak (Firebase + BigQuery + custom services) gangbaar. Voor B2B-SaaS schaalt het tot tientallen duizenden tenants.

De technische limieten

Firebase-services hebben harde limieten, maar ze liggen meestal hoog:

Firestore — 1 miljoen concurrent connections per database, 10.000 writes/sec per database (auto-scaling), 1MB per document. Praktisch onbeperkte opslag.
Authentication — geen harde limiet op aantal gebruikers; tot miljarden ondersteund.
Cloud Functions — 1.000 concurrent executions/region default (op te schalen), 9 minuten max executietijd, 8GB memory max.
Storage — 5 PB per bucket. In de praktijk nooit geraakt.
Hosting — 250GB transfer/maand op Blaze plan (additioneel betalen), CDN over 100+ POPs.

De limieten zijn voor 99% van de apps geen showstopper. Knelpunten ontstaan elders.

Waar je in praktijk vastloopt

1. Complexe queries. Firestore ondersteunt geen JOINs en heeft beperkingen op compound queries (combinaties van WHERE-clauses). Voor analytics-achtige queries moet je denormaliseren of naar BigQuery exporteren.
2. Read-volume kosten. Firestore rekent per document-read. Bij apps met veel listings (een tabel met 1.000 items = 1.000 reads) kan het snel oplopen. Caching wordt cruciaal.
3. Single-region writes. Firestore is multi-region voor reads (replicas), maar writes gaan naar één primary region. Bij globale apps met veel writes: latency-issue.
4. Functions cold-start. Cloud Functions hebben 1-5 seconden cold-start bij idle. Voor latency-kritische APIs: of houden warm of switchen naar Cloud Run.
5. Vendor lock-in. Geen technische limiet maar wel een strategische: migratie weg van Firebase is duur, dus check vooraf je 3-jaar plan.

Hoe ver kom je echt? Praktische cases

B2C consumer app, <1M MAU: Firebase comfortabel. Kosten beheersbaar (€200-€2.000/maand).
B2C app, 1M-10M MAU: Firebase werkt, mits goed ontworpen. Kosten €2.000-€20.000/maand. Caching en query-optimalisatie cruciaal.
B2C app, 10M+ MAU: Vaak hybride. Firebase voor auth + Firestore voor user-data, maar analytics en feeds via BigQuery/Pub/Sub.
B2B SaaS, <1.000 tenants: Prima op Firebase. Multi-tenancy via subcollections of een tenant-id-veld.
B2B SaaS, 10.000+ tenants: Werkt nog, maar dwingt tot architecturale keuzes. Enterprise-features (audit-logs, isolatie) bouwen erbij.
Regulated/compliance-zwaar (zorg, banking): Hier wordt Azure of AWS vaak verkozen om compliance-redenen, niet om technische.

Signalen dat je moet overstappen (of hybridiseren)

1. Je krijgt >€10.000/maand aan Firebase-kosten. Op die schaal verdient een hybride architectuur zich snel terug.
2. Je doet analytics op je productie-database. Slecht idee — exporteer naar BigQuery, doe analyse daar.
3. Je moet ACID-transacties over meer dan 5 documenten. Firestore-transacties zijn beperkt. Een PostgreSQL-database elders kan robuuster zijn.
4. Je hebt strenge compliance-vereisten. Sommige sectoren (zorg, finance, defensie) accepteren simpelweg geen Google-cloud zonder eigen sovereignty-cloud.
5. Je team moet schaal-engineering-keuzes maken die Firebase niet toestaat. Custom caching, custom sharding, etc.

Veelgemaakte fouten

Firebase opgeven “omdat schaalbaarheid”. Vaak een misverstand. Onderzoek eerst of jouw bottleneck echt schaal is, of een ontwerpkeuze.
Migrate as a panic-move. Als je kosten lopen, optimaliseer eerst (denormaliseer reads, cache aggregaten, denk je read-patterns opnieuw door). Migratie kost meer dan optimalisatie.
Negeren dat je app prima draait. Soms is een dure Firebase-rekening goedkoper dan een herbouw naar AWS. Reken het door.
Custom shardingoplossingen bouwen zonder echte noodzaak. Premature optimization.
Geen monitoring-dashboards. Zonder zicht op reads/writes per collectie weet je niet waar bottlenecks zitten.

Veelgestelde vragen

Welke grote apps draaien op Firebase?

Duolingo, Alibaba, NPR, The New York Times (deelapps), Halfbrick (Fruit Ninja), Twitch (chat-systeem), en duizenden SaaS-tools. Schaal is geen issue, mits goed ontworpen.

Kan ik Firebase combineren met PostgreSQL?

Ja. Veel apps gebruiken Firebase voor auth + real-time UX en een aparte PostgreSQL (via Supabase, Neon, of zelf-gehost) voor complexe relationele data. De combinatie werkt goed.

Hoe duur wordt Firebase echt bij 1M gebruikers?

Sterk afhankelijk van read-patronen. Een typische consumer-app met 1M MAU en gemiddeld 10 sessies/maand: reken op €3.000-€8.000/maand. Bij read-heavy use-cases (feeds, listings): €8.000-€20.000/maand zonder optimalisatie.

Is Firestore traag bij grote datasets?

Nee, Firestore queries blijven snel ongeacht collectie-grootte (logaritmische scaling). Wat traag wordt: het lezen van duizenden documenten in één query. Daarom: paginate altijd, cache aggregaten.

Kan ik makkelijk van Firebase naar Supabase migreren?

Niet makkelijk. Firestore is NoSQL, Supabase is PostgreSQL. Migratie vraagt schema-design, data-transformatie scripts, en applicatie-rewrite voor queries. Reken op 30-50% van de originele bouwtijd.

Heeft Firebase een SLA?

Op Blaze plan: 99.95% uptime SLA voor Firestore en Cloud Functions. Authentication: 99.9%. Voor MKB voldoende; voor mission-critical financial apps soms te laag — daar kies je AWS of Azure met dedicated tier.

Klaar om te beginnen?

Lees onze aanpak voor een Firebase-app laten bouwen, of vraag een offerte aan. Je krijgt binnen één werkdag een reactie, met een vaste prijs of een paar gerichte vragen.