Warum wir nie wieder Firebase nutzen

Firebase ist großartig — bis es das nicht mehr ist. Wir haben es über Jahre in mehreren Kundenprojekten eingesetzt. Echtzeit-Synchronisation out of the box, kein Server nötig, großzügiges Free Tier. Für Prototypen und Hackathons ist es schwer zu schlagen.

Aber jedes einzelne Projekt, das über die Prototyp-Phase hinauswuchs, ist an denselben Wänden gescheitert. Nach der dritten schmerzhaften Migration haben wir eine Entscheidung getroffen: PostgreSQL ist unser Standard. Ohne Ausnahmen.

Die Honeymoon-Phase

Seien wir fair. Firebase macht vieles richtig für Produkte in der Frühphase:

• Kein Backend-Setup nötig — einfach npm install firebase und los
• Echtzeit-Listener mit onSnapshot fühlen sich wie Magie an
• Authentifizierung in Minuten statt Tagen
• Hosting, Storage und Functions in einem Ökosystem

Wir haben wirklich gerne damit gebaut. Die ersten Wochen eines Firebase-Projekts fühlen sich unglaublich produktiv an.

Wo es auseinanderfällt

1. NoSQL = NoSafety

Firestore hat kein Schema. Das klingt nach Freiheit. In der Praxis ist es Chaos.

// Firestore: hoffen wir das Beste
const userDoc = await getDoc(doc(db, "users", id));
const data = userDoc.data(); // Typ: DocumentData | undefined
// Welche Felder existieren? Wer weiß. Schau in die Console.

// PostgreSQL + Prisma: exakt wissen was kommt
const user = await prisma.user.findUnique({
  where: { id },
  select: { name: true, email: true, role: true },
});
// user ist voll typisiert. IDE-Autocomplete funktioniert.
// Tippfehler sind Compile-Errors.

Ein Tippfehler in einem Firestore-Feldnamen wirft keinen Fehler — er erstellt stillschweigend ein neues Feld. Wir haben ganze Debugging-Sessions damit verbracht, Probleme aufzuspüren, die sich als userName vs username vs user_name quer durch die Codebase herausstellten.

2. TypeScript endet an der Netzwerkgrenze

Das ist der entscheidende Punkt. Man kann das schönste typisierte TypeScript-Frontend der Welt haben, und Firestore gibt einem trotzdem any auf der Datenbankebene.

Ja, man kann Converter nutzen. Ja, man kann Zod-Schemas schreiben. Aber man pflegt die Types doppelt — einmal im Code und einmal im Kopf, in der Hoffnung, dass sie mit dem übereinstimmen, was tatsächlich in der Datenbank liegt.

Mit Prisma werden die Types aus dem Schema generiert. Eine einzige Quelle der Wahrheit. Schema ändern, prisma generate ausführen, und TypeScript zeigt überall, wo der Code aktualisiert werden muss.

// prisma/schema.prisma — das IST die Wahrheit
model Order {
  id        String   @id @default(cuid())
  status    OrderStatus
  total     Decimal
  items     OrderItem[]
  createdAt DateTime @default(now())
}

enum OrderStatus {
  PENDING
  CONFIRMED
  SHIPPED
  DELIVERED
}

Versuch das mal mit Firestore. Man kann kein Enum auf Datenbankebene erzwingen. Man kann nicht garantieren, dass ein Feld existiert. Man kann keine referentielle Integrität sicherstellen.

3. Security Rules sind eine eigene Sprache

Firestore Security Rules sind eine eigene DSL ohne IDE-Support, ohne echtes Unit-Testing-Framework (ja, es gibt den Emulator, aber der ist umständlich) und mit Fehlermeldungen, die sich wie Rätsel lesen.

// Firestore Rules — viel Glück beim Debuggen
match /orders/{orderId} {
  allow read: if request.auth != null
    && resource.data.userId == request.auth.uid;
  allow write: if request.auth != null
    && request.resource.data.keys().hasAll(['status', 'total'])
    && request.resource.data.status in ['pending', 'confirmed'];
}

Vergleich das mit Middleware in Next.js oder Row-Level Security in PostgreSQL — Tools mit echtem Type Checking, Testing-Frameworks und jahrelangem Ökosystem-Support.

4. Kostenüberraschungen

Firestore rechnet pro Dokument-Read ab. Klingt simpel, bis man realisiert:

• Eine Listenansicht mit 50 Einträgen = 50 Reads
• Ein Echtzeit-Listener auf diese Liste = 50 Reads bei jeder Änderung
• Paginierung kostet trotzdem Reads für übersprungene Dokumente
• Es gibt kein SELECT COUNT(*) — entweder pflegt man einen Counter oder liest jedes Dokument

Ein Kunde hatte einen Monatskostenanstieg von 30€ auf 800€, weil eine einzige Dashboard-Komponente kaskadierende Reads auslöste. Mit PostgreSQL zahlt man für Compute, nicht für Queries.

5. Vendor Lock-In ist real

Jede Firestore-Query nutzt proprietäre Syntax. Jede Security Rule ist plattformspezifisch. Jede Cloud Function ist an das Firebase-Ökosystem gebunden.

SQL gibt es seit 50 Jahren. Die eigenen Queries funktionieren auf PostgreSQL, MySQL, SQLite, CockroachDB, PlanetScale, Neon, Supabase und hundert anderen Datenbanken. Das Wissen ist übertragbar. Der Code ist portabel.

Was wir stattdessen nutzen

Unser aktueller Standard-Stack:

Wann Firebase trotzdem Sinn macht

Wir sind nicht dogmatisch. Firebase ist eine gute Wahl wenn:

• Man eine Echtzeit-Consumer-App mit einfachen, flachen Daten baut
• Das Team klein ist und keine Backend-Expertise hat
• Man einen Prototyp in Tagen statt Wochen braucht
• Langfristige Wartbarkeit keine Rolle spielt (Hackathons, Experimente)

Aber für alles, was wachsen, sich weiterentwickeln und von einem Team gewartet werden soll? SQL gewinnt. Jedes Mal.

Das Fazit

Wir hassen Firebase nicht. Wir hassen es, Produktionsprobleme um 2 Uhr nachts zu debuggen, weil ein Dokument staus statt status hatte und es drei Wochen lang niemand bemerkt hat.

Wir schlafen gerne nachts. Und PostgreSQL lässt uns das.

Du überlegst, von Firebase zu migrieren? Wir übernehmen Infrastruktur-Transitionen mit Zero Downtime. Erfahre mehr über unsere Cloud- & DevOps-Services.