Appwrite vs Supabase: unser Lasttest, Kosten und wann Self-Hosting gewinnt

Sie brauchen ein Backend für Ihre App: Login, Datenbank, Dateien. Appwrite und Supabase nehmen Ihnen genau das ab, beide sind Open Source, und beide können Sie in der Cloud nutzen oder selbst betreiben. Welches passt? Statt Marketingtexte zu vergleichen, haben wir beide auf denselben Servern einem Lasttest unterzogen.

Kurze Antwort: Nehmen Sie Appwrite, wenn Sie ein schlankes Backend auf einem eigenen, kleinen Server betreiben wollen. Nehmen Sie Supabase, wenn Sie eine verwaltete Postgres-Datenbank in der Cloud mit SQL-Werkzeugen wollen. Beide haben einen kostenlosen Tarif, und die bezahlten Cloud-Tarife starten bei 25 USD im Monat (Stand November 2026).

Was ist der Unterschied zwischen Appwrite und Supabase?

Kurz gesagt: Beide sind Backend-as-a-Service, also ein fertiges Backend mit Login, Datenbank, Dateispeicher und Funktionen, das Sie nicht selbst programmieren. Supabase ist um eine Postgres-Datenbank herum gebaut. Appwrite ist ein schlanker Server, der seit Version 2.0 ebenfalls standardmäßig PostgreSQL nutzt.

Ein Vergleich: Supabase ist die möblierte Wohnung mit Hausmeister. Das ist bequem, aber Sie zahlen für den Service und nutzen die Möbel, die da sind. Appwrite ist eher eine leichte Einbauküche, die Sie in jede Wohnung mitnehmen, auch in eine kleine.

Wie schnell sind Appwrite und Supabase im Lasttest?

Kurz gesagt: In unserem Lasttest vom September 2024 schaffte Appwrite auf jedem Server deutlich mehr gleichzeitige Nutzer als Supabase. Auf einem Hetzner CAX31 hielt Appwrite 250 virtuelle Nutzer in der Komfortzone, Supabase 45.

So haben wir getestet. Wir haben einen typischen Shop simuliert: 5.000 Nutzer und 20.000 Produkte in der Datenbank. Jeder virtuelle Nutzer lädt sein Profil, dann eine gefilterte, sortierte Produktliste, wartet eine Sekunde und fängt von vorn an. Das ist härter als echtes Verhalten, denn echte Nutzer schauen sich die Seite erst ein paar Sekunden an. Beide Backends liefen ohne Tuning, so wie sie installiert werden. Die Last erzeugten wir mit Grafana k6 über ein Mobilfunknetz, etwa 1.500 km vom Rechenzentrum in Deutschland entfernt.

• Komfortzone: die höchste Zahl gleichzeitiger Nutzer, bei der 90 % der Anfragen unter 200 ms, 95 % unter 500 ms und 99 % unter 1 Sekunde beantwortet werden, mit höchstens 1 % Fehlern. So fühlt sich eine App für Nutzer noch flüssig an.
• Belastungsgrenze: der Punkt, an dem der Server anfängt, mit Fehlern und Zeitüberschreitungen zu antworten. Er läuft dann noch, aber Nutzer warten oft viele Sekunden.

Bei Supabase hat der CAX21 fast genau dieselben Werte geliefert wie der CAX11, höchstens etwa 10 % Unterschied. Deshalb haben wir diesen Lauf abgekürzt. Auf dem CAX31 erreichte Appwrite die Belastungsgrenze bei 6.800 Nutzern, mit 100.000 verarbeiteten Anfragen und im Schnitt 3 Sekunden Antwortzeit. Supabase erreichte sie bei 3.000 Nutzern, mit 59.000 Anfragen und im Schnitt 6 Sekunden.

Auffällig war der Leerlauf. Auf dem CAX11 belegte Appwrite ohne jede Last etwa 30 % der Ressourcen, Supabase etwa 200 %, also zwei volle Kerne, dauerhaft. Wir haben das in der Cloud gegenprüft und ein ähnliches Bild gesehen. Supabase besteht aus vielen Diensten, die alle laufen, auch wenn niemand die App nutzt.

Ein ehrlicher Hinweis: Das sind Messwerte von 2024, mit den damaligen Versionen. Seitdem haben beide Projekte viel geändert. Alle Skripte und Rohdaten liegen öffentlich im Test-Repository auf GitHub, die Diagramme zu jedem Server zeigt unser ausführlicher Testbericht (EN). Sie können dieselben Szenarien mit Ihren eigenen Daten wiederholen.

Wie viele Nutzer schafft ein kleiner Server?

Kurz gesagt: mehr, als die meisten erwarten. Bei einer App mit 50.000 aktiven Nutzern im Monat rechnen wir in der Spitze mit etwa 20 gleichzeitigen Nutzern pro Minute. Das schaffte Appwrite in unserem Test schon auf dem kleinsten Server.

1. 50.000 Nutzer im Monat, aktiv an etwa 25 Tagen: rund 2.000 Nutzer am Tag.
2. Der meiste Traffic fällt in 8 Stunden: 2.000 / 8 = 250 Nutzer pro Stunde.
3. 250 Nutzer pro Stunde sind etwa 4 pro Minute. Mit Puffer für Spitzen rechnen wir mit 20 pro Minute.
4. Appwrite hielt auf dem CAX11 im harten Ein-Sekunden-Takt 60 gleichzeitige Nutzer in der Komfortzone.

Für den Anfang reicht also ein Server, der heute einige Euro im Monat kostet. Wächst die App, kombinieren Sie Server: einen starken für die Datenbank, einen kleinen für leichte Aufgaben. Ein vergleichbares Setup bei einem großen Cloud-Anbieter kostet nach unserer Erfahrung schnell über 100 EUR im Monat, und die Rechnung ist schwer vorherzusagen.

Cloud oder Self-Hosting: Wann lohnt sich ein eigener Server?

Kurz gesagt: Self-Hosting gewinnt, wenn Ihr Traffic planbar ist, Sie eine feste Monatsrechnung wollen und jemand im Team den Server pflegt. Die Cloud gewinnt, wenn Sie schnell starten wollen, der Traffic schwer vorherzusagen ist oder niemand Server betreiben möchte.

Der Preis des eigenen Servers ist Ihre Zeit: Updates, Backups, Überwachung. Das ist kein Hexenwerk, aber es muss jemand tun. Ein Mittelweg: Starten Sie in der Cloud und wechseln Sie später auf einen eigenen Server. Das geht mit Appwrite leichter als mit Supabase, weil Appwrite selbst gehostet weniger Ressourcen braucht und weniger Funktionen verliert.

Was kosten Appwrite und Supabase 2026?

Kurz gesagt: In der Cloud starten beide kostenlos und kosten im Pro-Tarif ab 25 USD im Monat, dazu nutzungsabhängige Kosten. Selbst gehostet zahlen Sie nur den Server, bei Hetzner für Neubestellungen ab etwa 6 EUR netto im Monat.

Prüfen Sie die Preise vor der Entscheidung bei Appwrite, Supabase und Hetzner. Bei uns läuft das Backend immer auf Ihrem eigenen Konto, Cloud oder Server. Was die App selbst kostet, zeigt unser Artikel Was kostet eine App?.

Was hat sich mit Appwrite 2.0 geändert?

Kurz gesagt: Appwrite 2.0 bringt PostgreSQL als Standarddatenbank und eine neue Engine für Anfragen. Damit fällt das wichtigste Argument weg, das früher für Supabase sprach: Wer SQL braucht, kann auch bei Appwrite bleiben.

• PostgreSQL als Standard: Seit dem 7. September 2026 gibt es Appwrite 2.0 zum Selbsthosten. Neue Installationen nutzen PostgreSQL, MariaDB und MongoDB stehen weiter zur Wahl. Bestehende Installationen werden nicht automatisch umgestellt.
• Neue Datenbanktypen: Tabellen, Dokumente und Vektoren für KI-Suche, etwa mit der Postgres-Erweiterung pgvector.
• Schlanker im Betrieb: Laut Appwrite läuft eine Standardinstallation jetzt mit etwa halb so vielen Containern. Den Durchsatz der neuen Engine haben wir selbst noch nicht gemessen.

Unsere Zahlen oben stammen aus der Zeit vor 2.0. Starten Sie heute ein neues Projekt, lassen Sie die Szenarien aus dem Repository mit Ihren eigenen Daten auf Appwrite 2.0 laufen, bevor Sie sich festlegen. Details stehen in der Ankündigung von Appwrite 2.0 für Self-Hosting.

Appwrite oder Supabase: Was empfehlen wir?

Kurz gesagt: Für eine neue App mit eigenem, schlankem Backend nehmen wir meist Appwrite. Supabase nehmen wir, wenn das Projekt schon darauf läuft, wenn das Team tief in SQL arbeitet oder wenn die verwaltete Cloud wichtiger ist als die Kosten pro Nutzer.

• Prototyp oder Test mit ersten Nutzern: kostenloser Tarif von Appwrite oder Supabase, in der Cloud.
• App mit planbarem Wachstum und festem Budget: Appwrite auf einem eigenen Server.
• Ihr Prototyp aus Lovable läuft schon auf Supabase: erst einmal dabei bleiben, die Datenbank ist selten das Problem.
• Viel SQL-Logik, Berichte, Postgres-Erweiterungen: Supabase in der Cloud, oder Appwrite 2.0 nach einem eigenen Test.

Viele Prototypen aus Lovable und Bolt laufen auf Supabase. Was nötig ist, damit so eine App in die Stores darf, steht in Lovable-App in den App Store. Wenn wir Ihre App bauen, wählen wir das Backend in der Phase Prototyp und Plan und schätzen dort auch die laufenden Kosten. Wie das abläuft, zeigt So arbeiten wir, die Preise stehen auf der Seite Preise.