Vergleichen / Firebase

Die Firebase-Alternative, die sekundengenau abrechnet, nicht pro Lesezugriff
Firebase rechnet pro Lesezugriff ab und gibt dir Functions statt eines Servers. Lizard gibt dir PostgreSQL 18, Redis 8, S3-kompatiblen Objektspeicher und einen langlebigen Prozess davor — mit einem Befehl bereitgestellt und sekundengenau nach gemessener Nutzung abgerechnet.
Warum Entwickler nach einer Firebase-Alternative suchen
Die Rechnung skaliert mit den Lesezugriffen, nicht mit den Nutzern
Firestore im Blaze-Tarif kostet $0.06 pro 100.000 Lesezugriffe, $0.18 pro 100.000 Schreibvorgänge und $0.18 pro GiB gespeichertem Speicher. Ein Listenbildschirm, der pro Öffnen 40 Dokumente liest, ist bei 100 Nutzern ein Rundungsfehler und bei 100.000 ein eigener Rechnungsposten.
Firestore ist nicht relational
Jeder Join wird zur Denormalisierung, und jede Denormalisierung wird zu einem Fan-out-Write, der abgerechnet wird. Firebase SQL Connect, im April 2026 von Data Connect umbenannt, bietet inzwischen einen Postgres-Pfad — was den Punkt einräumt.
Es gibt keinen Server
In Firebase bleibt zwischen Anfragen nichts am Leben. Functions und App Hosting sind beide request-getrieben, daher gibt es für einen langlebigen Consumer oder einen offenen Socket keinen Platz.
Ein SDK besitzt alles
Auth, Datenbank, Storage, Functions und Hosting sind ein einziges Produkt. Die Teile teilen sich ein Projekt, eine Konsole und eine Rechnung, und das Client-SDK zieht dich in die Nutzung von allem hinein.
Lizard vs. Firebase
Alle Zahlen aus den von Firebase veröffentlichten Preisen und unseren eigenen. Zuletzt geprüft: 27 August 2026.
| Verglichen nach | Lizard | Firebase |
|---|---|---|
| Datenbank | PostgreSQL 18, relational, in Sekunden bereit | Firestore, ein Dokumentenspeicher |
| Abrechnung der Datenbank | Gemessene CPU, Arbeitsspeicher und Festplatte, pro Sekunde | $0.06 pro 100.000 Lesezugriffe, $0.18 pro 100.000 Schreibvorgänge, $0.18 pro GiB gespeichert |
| Servercode | Ein langlebiger Prozess, keine Ausführungsobergrenze | Cloud Functions, pro Aufruf, mit Limits |
| WebSockets und Streaming | Normale langlebige Verbindungen | Streaming ja, bei Callable Functions der 2. Generation; WebSockets nein |
| Cache | Managed Redis 8, ein Befehl | Kein Firebase-Produkt — Google Cloud Memorystore über VPC |
| Objektspeicher | S3-kompatibel, jedes AWS SDK funktioniert | Cloud Storage for Firebase |
| Auth | Bring your own — Firebase Auth inklusive, wenn es dir gefällt | Firebase Auth, First-Party und wirklich gut |
| Kostenlose Stufe | $10 Testguthaben, 31 Tage gültig | 50.000 Lesezugriffe, 20.000 Schreibvorgänge und 20.000 Löschvorgänge pro Tag, im Blaze-Tarif |
Wann Firebase die bessere Wahl ist
Eine Mobile-App, die größtenteils ein Client ist, der mit einem Datenspeicher spricht, besonders am Anfang. Firebase Auth, Cloud Messaging, Offline-Sync und die Client-SDKs sind hervorragend und schwer nachzubauen, und das Free Tier trägt ein echtes Produkt erstaunlich weit. Firestore zu verlassen bedeutet außerdem nicht, Firebase Auth oder Cloud Messaging zu verlassen — das lässt sich problemlos mit jedem Backend kombinieren.
Wechsel von Firebase
Keine Dockerfile erforderlich — lizardpack erkennt den Stack und schreibt eine Dockerfile auf dem Build-Knoten. Wenn Ihr Repo bereits eine Dockerfile hat, wird sie unverändert verwendet.
Häufig gestellte Fragen
Supabase kommt dem gesamten Produktspektrum von Firebase am nächsten, mit Postgres statt Firestore. Appwrite und PocketBase sind die selbst hostbaren Optionen. Wenn die App aus einer clientseitigen Datenschicht herausgewachsen ist, ist eine eigene API neben einem Managed Postgres — was auf Lizard ein Befehl ist — meist die bessere Architektur.
Ja, und das ist oft der günstigste erste Schritt. Firebase Auth stellt JWTs aus, die dein eigenes Backend mit Googles öffentlichen Schlüsseln verifizieren kann, sodass du die Datenschicht auf Postgres umstellen kannst, während der Sign-in exakt dort bleibt, wo er ist. Cloud Messaging lässt sich genauso kombinieren.
Exportiere die Collections mit gcloud firestore export oder gehe sie mit dem Admin SDK durch, und entwirf zuerst das relationale Schema, statt Dokumentstrukturen einfach zu übernehmen — diese Neugestaltung ist der Großteil der Arbeit. Schreibe während des Übergangs in beide Systeme, verschiebe Lesezugriffe hinter ein Feature-Flag und schalte dann um.
Nicht einen, der wach bleibt. Cloud Functions laufen pro Aufruf mit Cold Starts und Ausführungslimits, und Firebase App Hosting deployt auf Cloud Run, ist aber weiterhin request-getrieben. Für einen Prozess, der Zustand zwischen Anfragen halten muss — ein Queue-Consumer, ein WebSocket-Server, ein Scheduler — brauchst du eine Plattform, die so einen Prozess ausführt.
Mit AI entwickeln. Mit Lizard ausliefern.
Du brauchst kein Plattform-Team, um live zu gehen. Deine ganze Cloud ist nur einen CLI-Befehl entfernt.
- Workspaces
- —
- Dienste
- —
- Add-ons
- —
- Bereitstellungen
- —