Backend-as-a-Service-Vergleich 2026: Firebase vs. Supabase vs. Appwrite vs. PocketBase vs. Nhost im Test

Stand August 2026 stellt sich Entwicklerinnen und Entwicklern – ob im Side-Project oder im Series-finanzierten Startup – bei jedem neuen App-Launch noch immer dieselbe Grundfrage: Baue ich den Server selbst, oder setze ich auf ein Backend as a Service, das Authentifizierung, Datenbank, Storage und Echtzeitfunktionen aus einer Hand liefert? Dieser BaaS-Vergleich stützt sich bewusst nicht auf Marktanteile oder Markenbekanntheit, sondern ausschließlich auf das, was jeder Anbieter genau jetzt tatsächlich auf seiner offiziellen Preisseite und in offiziellen Ankündigungen stehen hat. Nur so lässt sich vermeiden, dass man an veralteten Zahlen aus einem Monate alten Tutorial hängen bleibt.

Im vergangenen Jahr hat sich die Marktordnung in diesem Segment grundlegend verschoben. Supabase sicherte sich im Juni 2026 eine Series-F-Finanzierung über 500 Millionen US-Dollar und erreichte damit eine Bewertung von 10,5 Milliarden US-Dollar – getragen von der “Vibe-Coding”-Welle, in deren Zuge die Nutzerbasis seit der Series E eigenen Angaben zufolge auf mehr als das Doppelte gewachsen ist. Als Antwort darauf hat Firebase im April 2026 auf der Cloud Next das bisherige Data Connect in SQL Connect umbenannt und damit begonnen, sich Richtung PostgreSQL-Lager zu öffnen. Parallel dazu bilden die Open-Source- und Self-Hosting-Anbieter Appwrite, PocketBase und Nhost eine Verfolgergruppe auf den Plätzen drei bis fünf, die gezielt die Nachfrage nach “Vendor-Lock-in-Vermeidung” bedient – für Entwickler, die gerade jetzt ein neues Backend auswählen, war die Auswahl damit noch nie so groß wie heute.

Dieser Artikel vergleicht die fünf Anbieter Firebase (Google), Supabase, Appwrite, PocketBase und Nhost detailliert in acht Abschnitten – von der Datenbank-Designphilosophie über die tatsächlichen Preismodelle und die Self-Hosting-Fähigkeit bis zur Empfehlung nach Nutzertyp. Im Zentrum stehen dabei die drei Achsen, an denen bei jedem BaaS-Vergleich kein Weg vorbeiführt: das Datenbankmodell (NoSQL vs. PostgreSQL vs. SQLite), die Preisobergrenzen-Struktur (nutzungsbasierte Abrechnung ohne Deckel vs. Abo-Modell vs. komplett kostenlos) und die Frage des Vendor-Lock-in. Wer die Datenbank-Engines selbst noch tiefer vergleichen möchte, findet ergänzend im Artikel PostgreSQL, MySQL und MongoDB im Datenbankvergleich weiterführende Informationen.

1. Executive Summary: Der BaaS-Vergleich auf einen Blick

Für Entwicklerinnen und CTOs, die keine Zeit zu verlieren haben, sind die wichtigsten Fakten zu den fünf führenden BaaS-Anbietern (Stand August 2026) hier in einer einzigen Tabelle zusammengefasst.

📊 Der große BaaS-Vergleich: 5 Backend-Anbieter im Überblick (Stand August 2026)

Die Zeile, die in dieser Tabelle am meisten Aufmerksamkeit verdient, ist die “Preisobergrenzen-Struktur”. Bei Firebases Blaze-Plan wird immer wieder darauf hingewiesen, dass es schlicht keine Hard-Cap gibt – schießt der Traffic nach oben, können die Kosten entsprechend schnell mitziehen. PocketBase dagegen kennt von vornherein gar kein Abrechnungssystem, hier muss man sich nur um die Serverkosten kümmern. Genau das ist der Punkt, den man in diesem BaaS-Vergleich bei der Budgetplanung zuerst prüfen sollte.

2. Deep Dive: Die Kernfunktionen der 5 Backend-Anbieter

🔥 1) Firebase – das vollständige Google-Ökosystem, jetzt auch mit SQL

• Von NoSQL-Fokus zur Öffnung Richtung PostgreSQL: Firebase läuft ohne eigene Versionsnummer als Sammlung einzelner Produkte – Firestore, Realtime Database, Authentication, Cloud Storage, Cloud Functions, Hosting. Auf der Google Cloud Next im April 2026 wurde bekanntgegeben, dass das bisherige Firebase Data Connect in Firebase SQL Connect umbenannt und dabei funktional erweitert wird: Auf Basis von Cloud SQL for PostgreSQL unterstützt es jetzt Echtzeit-Synchronisierung und Offline-Caching, und statt GraphQL kann man direkt native SQL-Abfragen schreiben. Dank einer 90-tägigen kostenlosen Testphase (keine Kreditkarte nötig) lässt sich sofort eine PostgreSQL-Instanz starten – die alte Vorstellung, Firebase sei “nur NoSQL”, trifft damit nicht mehr zu.
• Limits des kostenlosen Spark-Plans: Kostenlos sind 1 GiB Firestore-Speicher, 50.000 Dokument-Lesevorgänge pro Tag, je 20.000 Schreib- und Löschvorgänge pro Tag, 100 gleichzeitige Realtime-DB-Verbindungen, 50.000 MAU bei Authentication, 5 GB Cloud Storage sowie 10 GB Hosting-Speicher und 360 MB Transfer pro Tag.
• Das Risiko des nutzungsbasierten Blaze-Plans: Beim Upgrade auf Blaze bleiben die Free-Limits weiterhin kostenlos, danach greifen die regulären Google-Cloud-Tarife. Eine Kreditkarte ist Pflicht, und es gibt keinerlei Ausgabenobergrenze (Hard-Cap). Immer wieder wird darauf hingewiesen, dass die Rechnung bei einem unerwarteten Traffic-Spike entsprechend schnell explodieren kann. Cloud Functions sind bis 2 Millionen Aufrufe pro Monat kostenlos, danach werden 0,40 $ pro Million Aufrufe berechnet.
• Die genauen Preise sollte man selbst nachprüfen: Der exakte Preis pro 100.000 Firestore-Operationen wich zum Zeitpunkt der Recherche je nach Quelle deutlich voneinander ab, und die offizielle Seite firebase.google.com/pricing selbst enthält keine detaillierte Tabelle, sondern verweist lediglich per Link auf cloud.google.com/firestore/pricing. Für die reale Budgetplanung empfiehlt es sich, die aktuelle Tabelle unter diesem Link direkt selbst zu prüfen.

⚡ 2) Supabase – die Open-Source-Alternative mit 10,5-Milliarden-Dollar-Bewertung

• Das durch die Series F bestätigte Wachstum: Am 4. Juni 2026 sicherte sich Supabase unter Führung von GIC eine Series-F-Finanzierung über 500 Millionen US-Dollar und erreichte damit eine Bewertung (post-money) von 10,5 Milliarden US-Dollar. Sämtliche bisherigen Investoren – Accel, Y Combinator, Craft, Felicis, Peak XV, Coatue – beteiligten sich erneut, Stripe stieg über eine Sekundärtransaktion ein und Salesforce Ventures kam neu hinzu. Die Runde folgte nur sieben Monate nach der vorangegangenen Series E, womit sich das insgesamt eingesammelte Kapital auf über 1 Milliarde US-Dollar summiert. Dieser Finanzierungsverlauf ist durch Berichte von TechCrunch, CNBC und PR Newswire gegenseitig bestätigt.
• Der grundlegende Unterschied: reines PostgreSQL: Die Datenbank-Engine ist unverändert Managed PostgreSQL und unterstützt über die pgvector-Erweiterung nativ KI-Embeddings und Vektorsuche. Dazu kommen Auth, Storage (inklusive CDN), Edge Functions (auf Deno-Basis) und Realtime (auf Basis des Postgres-Change-Streams) – und da alles Open Source ist, lässt sich das Ganze auch direkt per Docker selbst hosten.
• Multigres in der Preview: Mit Multigres wurde eine neue Technologie als Preview vorgestellt, die Postgres über die Grenzen einer Einzelinstanz hinaus horizontal skalierbar machen soll. Eigenen Angaben zufolge zielt man dabei auf eine Skalierung “bis in Größenordnungen wie bei OpenAI” ab, ein konkreter GA-Termin wurde aber noch nicht genannt.
• Preismodell: Free bietet pro Projekt kostenlos 500 MB Datenbank, 1 GB Storage, 50.000 MAU und 5 GB Egress, allerdings pausiert das Projekt nach einer Woche Inaktivität, und es sind maximal 2 aktive Projekte erlaubt. Pro kostet 25 $/Monat (pro Projekt) und enthält 8 GB Datenbank (0,125 $ je zusätzlichem GB), 100 GB Storage (0,0213 $ je zusätzlichem GB), 100.000 MAU (0,00325 $ je zusätzlicher Person) sowie 250 GB Egress (0,09 $ je zusätzlichem GB). Team kostet 599 $/Monat mit denselben Limits wie Pro, ergänzt um SOC2-/ISO-27001-Konformität, 14 Tage Backup-Historie und bevorzugten Support. Auf der offiziellen Seite findet sich allerdings weiterhin der Hinweis, dass sich “die Preise noch in der Beta befinden und sich ändern können” – vor Vertragsabschluss lohnt sich also ein weiterer Blick auf die aktuelle Seite.
• Wachstumskennzahlen: Nach eigenen Angaben hat sich die Nutzerbasis seit der Series E mehr als verdoppelt, die Zahl der Datenbanken ist im Jahresvergleich um 600 % gestiegen, und Claude Code wurde als “seit Jahresbeginn größte einzelne Zuwachsquelle” genannt. Die GitHub-Stars knackten im Mai 2026 die Marke von 100.000.

🟪 3) Appwrite – Self-Hosting komplett kostenlos, acht Dienste an Bord

• Stabile Version 1.9.6: Appwrite ist ein Open-Source-BaaS mit Self-Hosting-Priorität, dessen aktuelle stabile Version Stand 2026 1.9.6 ist (veröffentlicht am 22. Juli 2026 als Korrektur-Release im Anschluss an 1.9.5). Seit der 1.9er-Linie ist MongoDB die Standard-Datenbank-Engine (MariaDB lässt sich weiterhin wählen), und mit Auth, Database, Storage, Functions, Messaging, Realtime, Sites (Web-Hosting) und Imagine (Bildgenerierung) bietet Appwrite acht Dienste – und positioniert sich damit selbstbewusst als funktional “umfangreicher als Firebase”.
• Self-Hosting ist wirklich kostenlos: Das Deployment gelingt mit einem einzigen Docker-Compose-Befehl, und beim Self-Hosting fällt seitens Appwrite überhaupt keine nutzungsbasierte Gebühr an – zu tragen sind nur die eigenen Server-Infrastrukturkosten. Das ist ein entscheidender Unterschied zu Firebase, Supabase Cloud und Nhost Cloud, und in diesem BaaS-Vergleich eine Option, die Teams mit knappem Budget unbedingt in Betracht ziehen sollten.
• Cloud-Preismodell: Free umfasst kostenlos 500.000 DB-Lesevorgänge/Monat, 250.000 Schreibvorgänge/Monat, 2 GB Storage, 5 GB Bandbreite/Monat und 75.000 MAU. Pro startet laut offizieller Seite ab 25 $/Monat und erweitert auf 1,75 Millionen Lesevorgänge/Monat, 750.000 Schreibvorgänge/Monat, 150 GB Storage, 2 TB Bandbreite/Monat und 200.000 MAU. Allerdings finden sich in manchen Drittquellen auch Angaben von “15 $/Monat (pro Organisationsmitglied)”, was der offiziellen Zahl (ab 25 $) widerspricht – die genaue Abrechnungseinheit sollte vor Vertragsabschluss auf der offiziellen Seite noch einmal geprüft werden.
• GitHub-Stars und Funding: Stand Mai 2026 liegen die GitHub-Stars bei rund 56.100, das kumulierte Funding wird auf etwa 37 Millionen US-Dollar geschätzt – der genaue Zeitpunkt der jüngsten Finanzierungsrunde ließ sich jedoch nicht verifizieren.

🪶 4) PocketBase – die Einzel-Binärdatei in Go, die Königsklasse des komplett Kostenlosen

• v0.39.10 – noch vor v1.0: PocketBase ist ein auf Go basierendes Backend, das komplett in einer einzigen ausführbaren Datei steckt und dessen aktuelle Version am 30. Juli 2026 bei v0.39.10 liegt. Eingebaute SQLite-Datenbank, Realtime-Subscriptions, Authentifizierung, Datei-Storage und ein Admin-Dashboard sind alle in dieser einen Binärdatei enthalten. Allerdings befindet man sich noch vor v1.0.0 – so deutlich, dass die offizielle Dokumentation ausdrücklich davon abrät, PocketBase “in produktionskritischen Umgebungen” einzusetzen, und auch im August 2026 gibt es weiterhin keinen offiziellen Stable-Release-Tag.
• Komplett kostenlos, MIT-Lizenz: Es gibt weder eine Abo-Gebühr noch eine nutzungsbasierte Abrechnung noch überhaupt eine kostenpflichtige Stufe. Auch kommerzielle Einschränkungen fehlen – lizenzrechtlich ist es sogar erlaubt, das Ganze als kostenpflichtigen Dienst an Dritte weiterzuverkaufen. Die einzigen Kosten sind die eigenen Server für das Self-Hosting, die bei Hetzner schon ab rund 4 $ im Monat starten, während die lokale Entwicklungsumgebung komplett kostenlos bleibt.
• Die Grenzen der Single-Writer-Architektur: Weil die Datenbank eine einzelne SQLite-Datei ist, gibt es die grundlegende Einschränkung einer Single-Writer-Architektur. Community-Berichten zufolge hat PocketBase auf einem minimal ausgestatteten VPS (rund 6 $/Monat) auch schon über 10.000 gleichzeitige Realtime-Verbindungen bewältigt, doch die vorherrschende Einschätzung sieht die praktische vertikale Skalierungsgrenze bei etwa 10.000 bis 20.000 gleichzeitigen Nutzern, und horizontale Skalierung (Multi-Node) wird nicht unterstützt.
• Die jüngsten Änderungen drehen sich um Stabilisierung: In der 0.39.x-Linie wurde die CLI-Panic-Recovery zurückgenommen (bei einem Panic bleibt jetzt wieder ein Non-Zero-Exit erhalten), die Ladeanzeige der Log-Charts im UI verbessert, modernc.org/sqlite auf v1.55.0 aktualisiert, ein Bug behoben, der beim Hochladen großer Dateien den Speicherverbrauch in die Höhe schnellen ließ, und der Rate-Limiter auf das klassische Fixed-Window-Verfahren umgestellt – insgesamt also eher Stabilisierungsarbeit als große neue Features.

🔷 5) Nhost – die Kombination aus PostgreSQL und Hasura-GraphQL

• Postgres und Hasura – und ein Übergang zu Constellation: Nhost ist ein 2019 gegründeter Open-Source-Managed-BaaS, der Managed PostgreSQL, eine auf Hasura basierende Echtzeit-GraphQL-API, Auth mit Social-Login und Magic Links, CDN-gestützten Datei-Storage, Serverless Functions und Custom-Container-Deployment in einem einzigen Stack bündelt. Am 3. Juni 2026 hat Nhost jedoch Constellation als Open Source veröffentlicht, eine neue GraphQL-Engine, die nahezu ein Drop-in-Ersatz für Hasura Community Edition ist – die Formel “PostgreSQL + Hasura” ist damit nicht mehr in Stein gemeißelt. Die in Go geschriebene Engine soll bei vergleichbarem Traffic rund 90 % weniger Arbeitsspeicher als Hasura benötigen; aktuell laufen beide parallel (Hasura für die Metadatenverwaltung, Constellation für die Verarbeitung der GraphQL-Anfragen), während der Umstieg schrittweise erfolgt.
• Open-Source-Veröffentlichung von “Nhost MCP” im März 2026: Am 31. März 2026 veröffentlichte Nhost seinen Dienst “Nhost MCP” als Open Source und unterstützt damit das Model Context Protocol. Die genauen technischen Details ließen sich nicht verifizieren. (Zur Einordnung: Das neue JavaScript-SDK erschien tatsächlich bereits im September 2025 und ist keine Ankündigung aus 2026.)
• Preismodell: Starter (kostenlos) bietet 1 GB Datenbank, 1 GB Storage und 5 GB Egress (ein Projekt, das bei Inaktivität pausiert wird). Pro kostet ab 25 $/Monat (inkl. 15 $ Compute-Guthaben) und enthält 10 GB Datenbank (0,20 $ je zusätzlichem GB), 50 GB Storage (0,05 $ je zusätzlichem GB) und 50 GB Egress (0,10 $ je zusätzlichem GB); Functions sind bis 50 inklusive (danach 5 $ je weitere 50), Ausführungszeit bis 10 GB-Stunden inklusive (danach 0,18 $ je GB-Stunde). Team übernimmt dieselben Limits wie Pro (10 GB Datenbank, 50 GB Storage, 50 GB Egress) und ergänzt SOC2-Type-II-Konformität, ein E-Mail-SLA und die Anbindung externer Datenbanken – ab 599 $/Monat. Enterprise ist bei sämtlichen Limits vollständig individuell, inklusive dediziertem Cluster und dediziertem technischem Account Manager, nennt aber keinen veröffentlichten Startpreis – hier gilt ausschließlich “auf Anfrage”.
• Klein, aber stabil: Das kumulierte Funding liegt bei rund 3,4 Millionen US-Dollar und damit deutlich unter dem von Supabase. Zum Zeitpunkt der Recherche fanden sich jedoch keine negativen Ereignisse wie eine Abschaltung oder Übernahme – für kleinere Teams, die eine GraphQL-First-Architektur wollen, bleibt Nhost damit weiterhin eine valide Option.

3. Duell der Datenbankmodelle und Skalierbarkeits-Benchmarks

[BaaS-Vergleich Stand August 2026 — qualitative Einschätzung]
Supabase (PostgreSQL)   : ⭐⭐⭐⭐⭐ Relationale Queries, Joins, pgvector, stark bei hoher Schreib-Nebenläufigkeit
Firebase (Firestore)    : ⭐⭐⭐⭐☆ Bewährte NoSQL-Skalierbarkeit auf Google-Infrastruktur
Appwrite (MongoDB)      : ⭐⭐⭐⭐☆ Dokumentenbasierte DB + Flexibilität durch Self-Hosting
Nhost (Postgres+Hasura/Constellation) : ⭐⭐⭐⭐☆ Automatische GraphQL-Generierung, volle Postgres-Stabilität
PocketBase (SQLite)     : ⭐⭐⭐☆☆ Stark bei niedriger Lese-Nebenläufigkeit, Grenzen bei gleichzeitigen Schreibzugriffen

In diesem BaaS-Vergleich ist es letztlich das Datenbankmodell, das den praktischen Leistungsunterschied bestimmt. In den recherchierten Vergleichsartikeln taucht immer wieder dieselbe qualitative Einschätzung auf: “Bei niedriger Lese-Nebenläufigkeit hat PocketBase die Nase vorn, sobald aber komplexe Joins oder hohe Schreib-Nebenläufigkeit ins Spiel kommen, liegt Supabase Pro insgesamt vorn.” Das ist jedoch keine offizielle Benchmark, sondern eine qualitative Einschätzung auf Basis sekundärer Vergleichsartikel – sobald der reale Service wächst, empfiehlt sich eine eigene Lasttest-Verifizierung.

Die Single-Writer-Architektur von PocketBase schlägt sich Community-Berichten zufolge selbst auf einem minimal ausgestatteten VPS für 6 $/Monat wacker – dort wurden schon über 10.000 gleichzeitige Realtime-Verbindungen bewältigt –, allerdings sollte man berücksichtigen, dass es sich dabei um Community-Berichte und nicht um offizielle Benchmarks handelt. Supabase hingegen kann auf der bewährten relationalen Datenbank PostgreSQL zusätzlich pgvector aufsetzen und ist damit für Projekte mit Bedarf an KI-Embeddings und Vektorsuche praktisch die erste Wahl, die man prüfen sollte. Wer die grundlegenden Unterschiede der Datenbank-Engines selbst (relational vs. NoSQL vs. In-Memory) noch breiter vergleichen möchte, findet im Artikel PostgreSQL, MySQL, MongoDB und Redis im Datenbankvergleich die grundlegenden Designunterschiede jeder Engine.

Auch Nhost kündigt in diesem Bild eine Verschiebung an. Die am 3. Juni 2026 veröffentlichte Engine Constellation – ein Open-Source-GraphQL-Ersatz, der nahezu ein Drop-in für Hasura Community Edition ist – soll bei vergleichbarem Traffic rund 90 % weniger Arbeitsspeicher benötigen als Hasura. Hasura ist damit noch nicht vollständig abgelöst, beide laufen vorerst parallel, doch die in diesem Artikel bislang verwendete Kurzformel “PostgreSQL + Hasura” für Nhost dürfte sich künftig zu “PostgreSQL + Hasura/Constellation” wandeln.

Auch mit Blick auf die Marktordnung werden interessante Verschiebungen berichtet. Manche Medien berichteten unter Berufung auf den CompTIA 2026 IT Outlook, dass Supabases Marktanteil im BaaS-Segment von 12 % im Jahr 2025 auf 28 % im ersten Quartal 2026 gestiegen sei – da sich der Originalbericht jedoch nicht direkt einsehen ließ und es sich um eine Sekundärquelle handelt, sollte man diese Zahl nur als groben Anhaltspunkt werten.

4. Preismodelle im vollständigen Vergleich

[Einstiegshürde in kostenpflichtige Tarife — nach monatlichem Mindestpreis]
PocketBase (Self-Hosting)  : 0 $         (keine Lizenzkosten, nur Serverkosten — Hetzner ab ca. 4 $)
Appwrite (Self-Hosting)    : 0 $         (Docker Compose, nur Server-Infrastrukturkosten)
Firebase (Blaze)           : ab 0 $      (nutzungsbasiert erst ab Überschreiten der Free-Limits, keine Hard-Cap)
Supabase (Pro)             : 25 $/Monat  (pro Projekt)
Appwrite (Cloud Pro)       : ab 25 $/Monat
Nhost (Pro)                : ab 25 $/Monat (inkl. 15 $ Compute-Guthaben)
Supabase (Team)            : 599 $/Monat
Nhost (Team)                : ab 599 $/Monat

💰 Detaillierter Preisvergleich

Bei den versteckten Kosten sind drei Punkte wichtig. Erstens: Die fehlende Hard-Cap bei Firebase Blaze wirkt in der frühen Startup-Phase harmlos, kann aber, sobald die App unerwartet viral geht, zu einer deutlich höheren Rechnung führen als erwartet. Es ist unbedingt ratsam, einen Budget-Alert einzurichten. Zweitens: Die Klausel “Pausierung nach einer Woche Inaktivität” bei Supabase Free greift tatsächlich, wenn man ein Side-Project länger liegen lässt. Wer es als Demo oder Portfolio-Projekt am Leben halten will, muss regelmäßig zumindest minimalen Traffic erzeugen oder auf Pro wechseln. Drittens: Die widersprüchlichen Angaben zur Abrechnungseinheit von Appwrite Pro zwischen offizieller Seite und Drittquellen müssen vor Vertragsabschluss unbedingt noch einmal geprüft werden. Je nachdem, ob sich “ab 25 $/Monat” auf die Organisation oder auf jedes Mitglied bezieht, kann sich bei wachsender Teamgröße ein erheblicher Unterschied in den Gesamtkosten ergeben.

Wer die Preisstruktur grundlegend anders angehen möchte, für den ist der Ansatz “die Plattform selbst ist kostenlos, es fallen nur Serverkosten an” – wie bei PocketBase oder beim Self-Hosting von Appwrite – ebenfalls eine valide Option in diesem BaaS-Vergleich. Wer konkret überlegt, wo ein solches selbst gehostetes Backend laufen soll, findet im Artikel Vercel, Netlify, Cloudflare, Render und Fly.io im Web-Hosting- & PaaS-Vergleich Plattformen, die auf Docker-Container-Deployment spezialisiert sind.

5. Die finale Empfehlung nach Nutzertyp

🎯 1) Große Teams, die bereits im Google-Cloud-/Firebase-Ökosystem verankert sind

• Die beste Wahl: Firebase
• Begründung: Die Integration mit der Google-Cloud-Infrastruktur sowie Auth, Hosting und Functions aus einer Hand bleiben nach wie vor stark. Die fehlende Hard-Cap beim Blaze-Plan sollte man aber unbedingt durch einen Budget-Alert absichern.

🎯 2) KI-Startups mit Bedarf an relationalen Queries und pgvector

• Die beste Wahl: Supabase
• Begründung: Auf reinem PostgreSQL sitzt pgvector nativ auf, sodass sich KI-Embeddings und Vektorsuche ohne separate Infrastruktur direkt anbinden lassen. Die Kapitalausstattung nach der Series F ist zudem belegt, das Risiko einer eingestellten Weiterentwicklung entsprechend niedrig.

🎯 3) Kleinere und mittlere Teams, die Vendor-Lock-in vermeiden und trotzdem einen breiten Funktionsumfang wollen

• Die beste Wahl: Appwrite
• Begründung: Self-Hosting ist komplett kostenlos und bietet gleichzeitig mit Auth, Database, Storage, Functions, Messaging, Realtime, Sites und Imagine acht Dienste in einem Paket. Nur die genaue Abrechnungseinheit von Cloud Pro sollte vor Vertragsabschluss noch einmal geprüft werden.

🎯 4) Einzelentwickler und MVPs, die Infrastrukturkosten auf ein Minimum drücken wollen

• Die beste Wahl: PocketBase
• Begründung: Es fallen überhaupt keine Lizenzkosten an, und als Go-Einzel-Binärdatei lässt sich der Service etwa bei Hetzner schon mit rund 4 $ Serverkosten im Monat betreiben. Die Skalierungsgrenzen bei gleichzeitigen Schreibzugriffen und der Umstand, noch vor v1.0 zu stehen, sollten vor dem Produktiveinsatz aber bedacht werden.

🎯 5) Teams, die eine automatisch generierte GraphQL-API schnell mit dem Frontend verbinden wollen

• Die beste Wahl: Nhost
• Begründung: Hasura generiert automatisch eine Echtzeit-GraphQL-API auf Basis des PostgreSQL-Schemas, sodass man REST-Endpunkte nicht mühsam von Hand schreiben muss. Angesichts des überschaubaren Fundingvolumens lohnt es sich aber, die langfristige Roadmap im Auge zu behalten.

🎯 6) Teams, die noch unentschlossen sind und mehrere Backends parallel abwägen

• Die beste Wahl: Prototyping mit Supabase Free oder lokal laufendem PocketBase
• Begründung: Beide lassen sich ohne Kreditkarte sofort starten (bei PocketBase braucht es nicht einmal ein Konto) – wer zunächst Schema-Design und Auth-Flow validiert und danach den Migrationsaufwand zu den übrigen Kandidaten vergleicht, geht das geringste Risiko ein.

6. Praxistipps und häufige Fehler

✅ Tipp 1) Bei Firebase Blaze zuerst unbedingt einen Budget-Alert einrichten

Beim Blaze-Plan beginnt die nutzungsbasierte Abrechnung, sobald die Free-Limits überschritten sind, und es gibt keine Ausgabenobergrenze. Wer nicht schon von Anfang an in der Google-Cloud-Console einen Budget-Alert einrichtet, merkt bei einem Traffic-Spike das Problem oft erst, wenn die Rechnung schon da ist.

✅ Tipp 2) Supabase-Free-Projekte nicht einfach liegen lassen

Ohne Aktivität über eine Woche hinweg wird das Projekt automatisch pausiert. Wer es als Portfolio- oder Demo-Projekt am Leben halten will, sollte regelmäßig zumindest minimale Health-Check-Anfragen senden oder innerhalb des Limits von zwei aktiven Projekten Prioritäten setzen.

✅ Tipp 3) Vor dem Appwrite-Pro-Vertrag die Abrechnungseinheit selbst noch einmal prüfen

Die offizielle Angabe von “ab 25 $/Monat” widerspricht der Angabe “15 $/Monat (pro Organisationsmitglied)” aus manchen Drittquellen. Bei größeren Teams kann sich dieser Unterschied bei der tatsächlichen Rechnung um ein Vielfaches auswirken – vor der Zahlung empfiehlt es sich, den aktuellen Wortlaut direkt auf appwrite.io/pricing zu prüfen.

✅ Tipp 4) Bei der Produktionsentscheidung berücksichtigen, dass PocketBase noch vor v1.0 steht

Die offizielle Dokumentation weist selbst ausdrücklich darauf hin, dass PocketBase “für produktionskritische Umgebungen nicht empfohlen” wird. Bei Diensten mit direktem Umsatzbezug ist es ratsam, regelmäßig die aktuellen Release Notes zu prüfen und parallel einen Migrationsplan bereitzuhalten.

✅ Tipp 5) Zuerst das Datenbankmodell festlegen, dann das BaaS wählen

Für Domänen mit vielen relationalen Joins und Transaktionen (E-Commerce, Buchungssysteme etc.) ist reines PostgreSQL bei Supabase oder Nhost im Vorteil, während für frühe Prototypen mit häufig wechselndem Schema Firebase Firestore oder MongoDB bei Appwrite flexibler sind. Wer die Kriterien für die Wahl der Datenbank-Engine selbst noch tiefer verstehen möchte, sollte zuerst den Artikel PostgreSQL, MySQL, MongoDB, Redis und DynamoDB im Vergleich lesen.

✅ Tipp 6) Wer Self-Hosting erwägt, sollte gleich auch die Deployment-Plattform mitplanen

Wer sich für das Self-Hosting von Appwrite oder PocketBase entscheidet, muss als Nächstes die Server- bzw. Container-Plattform für das Backend auswählen. Plattformen mit Stärken beim Docker-basierten Deployment finden sich im Artikel Vercel, Netlify, Cloudflare, Render und Fly.io im Vergleich, und wer eine größer dimensionierte Cloud-Infrastruktur benötigt, im Artikel AWS, GCP und Azure im Cloud-Anbieter-Vergleich.

7. Häufig gestellte Fragen (FAQ)

F: Welche Kriterien sollte man bei einem BaaS-Vergleich zuerst prüfen?

Drei Dinge: das Datenbankmodell (NoSQL vs. PostgreSQL vs. SQLite), die Preisobergrenzen-Struktur (nutzungsbasiert ohne Deckel vs. Abo-Modell vs. komplett kostenlos) und die Frage des Vendor-Lock-in, also ob Self-Hosting möglich ist. Wenn man allein diese drei Achsen klärt, schrumpft die Auswahl unter den fünf Kandidaten oft schon auf ein oder zwei tatsächlich relevante Optionen.

F: Was ist günstiger – Firebase oder Supabase?

Das hängt vom Einsatzzweck ab. Für Projekte mit geringem Traffic reichen sowohl Firebase Spark (Free-Limits) als auch Supabase Free (0 $/Monat) aus. Da Firebase Blaze aber keine Hard-Cap hat, wird die Kostenprognose mit steigender Nutzung schwieriger, während Supabase Pro mit 25 $/Monat (pro Projekt) einer fast pauschalen Struktur folgt und sich dadurch leichter budgetieren lässt.

F: Kann man PocketBase bedenkenlos in echten Produktionsumgebungen einsetzen?

Bei geringem Traffic (rund 10.000 bis 20.000 gleichzeitige Nutzer) gibt es Community-Berichte, denen zufolge PocketBase durchaus stabil läuft. Da die offizielle Dokumentation aber selbst noch vor v1.0.0 steht und ausdrücklich davon abrät, es “in produktionskritischen Umgebungen” einzusetzen, sollte man bei größeren, umsatzrelevanten Services vorsichtig vorgehen.

F: Appwrite und Supabase sind beide Open Source – worin unterscheiden sie sich?

Der größte Unterschied liegt in der DB-Engine und in der Abrechnungsstruktur beim Self-Hosting. Supabase nutzt reines PostgreSQL, Appwrite standardmäßig MongoDB (mit optionalem MariaDB). Außerdem fällt beim Self-Hosting von Appwrite außer den Serverkosten überhaupt keine Gebühr seitens Appwrite an, während sich die Preise von Supabase Cloud am Managed Service selbst orientieren.

F: Warum ist Nhost weniger bekannt als Supabase?

Mit einem kumulierten Funding von rund 3,4 Millionen US-Dollar ist Nhost im Vergleich zu Supabase (über 1 Milliarde US-Dollar an insgesamt eingesammeltem Kapital) deutlich kleiner aufgestellt. Der Unterschied bei Marketing- und Community-Größe scheint sich direkt in den Bekanntheitsgrad zu übersetzen – funktional (PostgreSQL + Hasura-GraphQL, seit Juni 2026 ergänzt um die eigene Engine Constellation) bleibt Nhost für GraphQL-First-Architekturen aber weiterhin konkurrenzfähig.

F: Ich möchte genau wissen, wie viel Firestore kostet – warum enthält dieser Artikel keine exakten Preise?

Bei der Recherche wichen die exakten Preise pro 100.000 Firestore-Operationen je nach Quelle stark voneinander ab, und auch die offizielle Seite firebase.google.com/pricing enthält keine detaillierte Tabelle, sondern verweist nur per Link auf cloud.google.com/firestore/pricing – eine verlässliche Zahl ließ sich damit nicht bestätigen. Für die reale Kostenkalkulation empfiehlt es sich, die aktuelle Tabelle unter diesem Link direkt selbst zu prüfen.

F: Ist es in Ordnung, mehrere der fünf BaaS-Anbieter zu mischen?

Das ist möglich. Eine gängige Kombination ist etwa, die Hauptapp auf Supabase laufen zu lassen und ein internes Admin-Tool schnell mit PocketBase hochzuziehen. Wird die Authentifizierung jedoch dupliziert, wird die Verwaltung der Nutzer-Sessions komplizierter – wer mehrere BaaS mischt, sollte daher zumindest die Auth-Schicht auf einen einzigen Anbieter vereinheitlichen.

F: Ist Self-Hosting in diesem BaaS-Vergleich wirklich komplett kostenlos?

Die reine Lizenzgebühr ist sowohl bei PocketBase als auch bei Appwrite tatsächlich 0 $. Server-Infrastrukturkosten (bei Hetzner, DigitalOcean & Co. mindestens ab ca. 4 $/Monat) und der Betriebsaufwand (Backups, Monitoring, Sicherheitspatches) bleiben aber weiterhin beim Nutzer selbst – korrekt ist also nicht “komplett kostenlos”, sondern “nur die Lizenz ist kostenlos”.

8. Fazit: Das praktische Ergebnis des BaaS-Vergleichs 2026

Stand August 2026 ist das Fazit dieses BaaS-Vergleichs eindeutig. Firebase und Supabase bilden ein Spitzenduo, während Appwrite, PocketBase und Nhost jeweils in ihrer eigenen Nische eine klare Präsenz behaupten. Supabase hat mit der Series F und der Bewertung von 10,5 Milliarden US-Dollar sowohl seine Kapitalstärke als auch sein Wachstum unter Beweis gestellt, während Firebase mit SQL Connect Richtung PostgreSQL-Lager expandiert und damit selbst die alte Wahrnehmung “nur für NoSQL” widerlegt.

In der Praxis ist es der sicherste Ausgangspunkt, zuerst das Datenbankmodell festzulegen. Wer relationale Queries und pgvector braucht, ist bei Supabase oder Nhost am besten aufgehoben; wer bereits im Google-Ökosystem steckt, bei Firebase; wer breite Funktionalität ohne Vendor-Lock-in will, bei Appwrite; und für Einzelprojekte, die Infrastrukturkosten auf ein Minimum drücken wollen, ist PocketBase jeweils die sinnvollste Wahl. Vergessen Sie dabei aber nicht die Punkte, die bei jedem Anbieter vor Vertragsabschluss noch einmal geprüft werden sollten: die fehlende Hard-Cap bei Firebase Blaze, die Pausierungsklausel bei Supabase Free, die widersprüchliche Abrechnungseinheit bei Appwrite Pro und der Status von PocketBase vor v1.0. Wer nach der Wahl des Backends über die tatsächliche Deployment-Infrastruktur nachdenkt, findet im Artikel Vercel, Netlify, Cloudflare, Render und Fly.io im Web-Hosting-Vergleich und – bei größer dimensionierten Cloud-Architekturen – im Artikel AWS, GCP und Azure im Cloud-Anbieter-Vergleich die nächsten hilfreichen Schritte.

[Zusammenfassung: die passende Empfehlung für Ihre Situation]

Große Teams im Google-Ökosystem
  → Firebase (Blaze, Budget-Alert unbedingt einrichten)

KI-Startups mit Bedarf an relationalen Queries und pgvector
  → Supabase (Pro 25 $/Monat, reines PostgreSQL + pgvector)

Teams, die Vendor-Lock-in vermeiden und breite Funktionalität brauchen
  → Appwrite (Self-Hosting komplett kostenlos, 8 Dienste)

Einzelentwickler mit Bedarf an maximaler Kosteneinsparung bei der Infrastruktur
  → PocketBase (Lizenz kostenlos, nur Serverkosten ab 4 $/Monat)

Teams mit GraphQL-First-Architektur
  → Nhost (Postgres + Hasura, Pro ab 25 $/Monat)

Noch unentschlossen und am Abwägen
  → Prototyping mit Supabase Free oder lokal laufendem PocketBase

Wer zuerst das Datenbankmodell und die Preisobergrenzen-Struktur des eigenen Projekts festlegt und darauf die aktuellen Tarife legt, dem wird unter den fünf in diesem BaaS-Vergleich behandelten Kandidaten deutlich klarer, wohin die tatsächliche Wahl fallen sollte.