Acht Convex-Alternativen verglichen. Ich wechsle nicht

Ich habe im Juli 2026 acht Convex-Alternativen verglichen und werde nicht wechseln. Appwrite ist der stärkste etablierte Konkurrent, InsForge der interessanteste neue. Convex bleibt trotzdem vorn, weil Schema, Funktionen, Jobs, Storage-Logik und Auth-Konfiguration gemeinsam als TypeScript vorliegen. Für meine KI-Agenten ist kein anderes Backend so einfach zu ändern.

So habe ich gewertet: Weniger Backend-Systeme schlagen niedrigere Preise

Ich habe danach gewertet, wie viele getrennte Systeme ein Agent verstehen muss, um eine Backend-Änderung vollständig umzusetzen. Dieses Kriterium war wichtiger als der Preis, denn fünf der neun günstigsten Bezahlpläne kosten zwischen 25 und 30 $ im Monat. Convex belegte Platz eins, InsForge Platz zwei und Appwrite Platz drei.

Der Funktionsumfang gab nicht den Ausschlag. Wichtiger war, ob ein Agent ein vollständiges Backend-Feature sehen und ändern kann, ohne mehrere Konfigurationssysteme zu durchqueren.

Warum funktioniert Convex so gut mit KI beim Programmieren?

Convex fühlt sich einfacher an, weil das gesamte Backend als Code in einem Ordner liegt. Schema, Queries, Mutations, geplante Jobs, Dateispeicher, Vektorindizes und Auth-Konfiguration stehen als TypeScript-Dateien direkt nebeneinander. Ein Agent kann ein Feature deshalb wie jedes andere Modul ändern, ohne zusätzlich ein Dashboard zu bedienen.

convex/
  schema.ts       # tables, indexes, vector indexes
  users.ts        # queries and mutations
  billing.ts      # actions calling Stripe
  crons.ts        # scheduled jobs
  http.ts         # webhook endpoints
  auth.config.ts  # auth providers

Das sind die tatsächlichen Dateien, die ein Agent vor der Umsetzung eines Features verstehen muss, und sie passen auf einen Bildschirm. Ein Feature für Einladungen mit Rate-Limit betrifft in meinen Projekten meist drei Dateien in diesem Ordner. Definiert das Modell die Daten falsch, melden die generierten Typen einen Fehler. Eine separate Änderung im Dashboard kann der Agent ebenfalls nicht vergessen, weil es sie nicht gibt.

Convex gibt Agenten außerdem direkten Zugriff auf das Backend. Laut der Anleitung im Convex Developer Hub wird das Claude-Code-Plugin mit /plugin install convex@claude-plugins-official installiert. Danach kann es Entwicklungsdaten und Logs lesen, Funktionen ausführen und die generierten Typen aktuell halten [1]. Die Codex-Anleitung bietet über MCP einen ähnlichen Zugriff und ergänzt die Subagenten convex-expert und convex-reviewer [2]. Mein Agent kann das echte Backend untersuchen, statt seinen Aufbau zu erraten.

Die Vektorsuche folgt demselben Prinzip: Ich deklariere einen vectorIndex im Schema, setze für OpenAI-Embeddings 1536 Dimensionen und frage ihn im Servercode ab [3]. Eine zweite Datenbank oder ein separater Synchronisationsprozess ist nicht nötig. Manche nennen diese Arbeitsweise Vibe Coding, doch der praktische Vorteil zählt mehr als das Etikett. Bei weniger beweglichen Teilen müssen der Agent und ich uns auch weniger merken.

Warum ich Convex statt Supabase für KI-Projekte gewählt habe

Supabase hat mich verloren, weil eine Backend-Änderung oft SQL-Migrationen, Row-Level-Security-Policies, Edge Functions, Storage-Regeln und generierte Typen berührte. Ich schätze das Postgres-Ökosystem, doch in meiner produktiven Arbeit gaben diese getrennten Teile den KI-Agenten mehr Möglichkeiten, eine Änderung nur teilweise umzusetzen.

Die Migrationsanleitung von Supabase beschreibt die nötige Disziplin klar. Ihre wichtigste Regel lautet, die entfernte Datenbank nie direkt zu ändern. Jede Schemaänderung wird deshalb zu einer SQL-Migration mit Zeitstempel, die lokal getestet, committed und anschließend gepusht wird. Eine Änderung im Dashboard kann die lokale und entfernte Version auseinanderlaufen lassen [4].

Das ist ein sinnvoller Entwicklungsprozess, gibt einem KI-Agenten aber mehr Möglichkeiten für eine unvollständige Änderung. In meinen Projekten aktualisierten Agenten regelmäßig vier Teile und vergaßen den fünften. Convex beseitigt genau diesen Fehler, weil der fünfte Ort nicht existiert.

Auch bei Convex kann eine Schemaänderung ein Backfill vorhandener Daten erfordern. Der Code dafür bleibt jedoch neben dem übrigen Backend, statt in einer parallelen Kette aus Dateien und Tools zu landen.

Warum die anderen Convex-Alternativen nicht ausreichen

Bei jeder weiteren Alternative fehlt ein anderer Teil des Ablaufs, den ich suche. Appwrite kann viel, verteilt das Backend aber auf Ressourcen. InstantDB braucht eine zweite Plattform für Serverlogik, während ich das Backend bei Cloudflare selbst zusammensetzen muss. Firebase, Nhost und Encore.ts bringen ähnliche Kompromisse mit.

Appwrite ist die stärkste etablierte Alternative

Appwrite ist die stärkste etablierte Komplettalternative, besonders wenn skalierbare Auth wichtiger ist als eine gemeinsame Codebasis. Der Plan für 25 $ im Monat gilt für die gesamte Organisation und enthält 200.000 monatlich aktive Nutzer, 150 GB Storage, 2 TB Bandbreite, 3,5 Millionen Function-Ausführungen und tägliche Backups [5].

Appwrite stellt außerdem Agent-Skills für neun SDKs in Claude Code, Codex und Cursor bereit [6]. Seine MCP-Server können Datenbanken, Nutzer und Dateien direkt verwalten [7]. Die Unterstützung für Agenten ist also umfangreich. Wenn du mit Cursor arbeitest, habe ich beschrieben, warum dort das Agents Window zuerst erscheinen kann und wie du die IDE zurückholst.

Appwrite landete trotzdem auf Platz drei, weil sein Backend aus Ressourcen wie Buckets, Berechtigungen und Zeitplänen besteht. Ich kann es nicht als eine gemeinsame Codebasis lesen. Bei der Vektorsuche kommt eine weitere Grenze hinzu: Appwrites eigene Anleitung verbindet eine Function mit OpenAI für Embeddings und nutzt einen externen Pinecone-Index für die Suche [8]. Genau diesen zusätzlichen Dienst wollte ich vermeiden.

InstantDB braucht eine zweite Plattform für Serverlogik

InstantDB kommt dem Ablauf von Convex am nächsten, deckt aber nur einen Teil meines Backends ab. Schema und Berechtigungen sind Code, und Agenten können über einen MCP-Server Anwendungen erstellen und Änderungen an beiden pushen. InstantDB stellt außerdem Instruktionsdateien für Claude Code und Codex bereit [9].

Der kostenlose Tarif enthält 1 GB, unbegrenzt viele API-Anfragen und keine automatische Pausierung. Der Pro-Tarif für 30 $ erhöht den Storage auf 10 GB und ergänzt zehn Teammitglieder sowie tägliche Backups [10]. Das sind attraktive Bedingungen, lösen aber nicht die fehlenden serverseitigen Funktionen.

InstantDB ist eine Sync-Engine mit Auth und Storage, aber kein Ort für Serverlogik. Die Dokumentation behandelt Presence, Cursor, Berechtigungen und eine Admin-HTTP-API, jedoch keine gehosteten Functions, Cronjobs oder Vektorsuche [11]. Für die serverseitige Hälfte meines Produkts bräuchte ich weiterhin eine zweite Plattform. Damit erfüllt InstantDB meine Anforderungen nicht.

Cloudflare ist günstig, aber kein einheitliches Backend

Cloudflare hat den niedrigsten Einstiegspreis, erfordert für einen vergleichbaren Funktionsumfang aber mehrere getrennte Produkte. Der Plan für 5 $ im Monat enthält 10 Millionen Anfragen und 30 Millionen CPU-Millisekunden [12]. Vectorize liefert dazu eine Vektordatenbank, die sich direkt mit Workers verbinden lässt [13].

Für ein vollständiges Backend muss ich Workers, D1, R2, Queues und Vectorize kombinieren. Jedes Produkt hat eine eigene Konfiguration, und Auth für Endnutzer muss ich separat ergänzen. Auch der EU-Datenstandort verlangt Aufmerksamkeit: D1 kann eine Datenbank in einer EU-Jurisdiktion halten, Workers dürfen aber weiterhin von überall darauf zugreifen. Die Standortbeschränkung gilt für die Datenbank, nicht für das Compute [14].

Firebase bleibt eine Sammlung getrennter Produkte

Firebase bleibt konkurrenzfähig. Auth ist für bis zu 50.000 monatlich aktive Nutzer kostenlos, bevor die Preise der Google Cloud Identity Platform greifen [15]. Es handelt sich weiterhin um mehrere Google-Cloud-Produkte mit eigenen Konsolen und Preisen. Deshalb erfüllt Firebase meine Anforderung an eine gemeinsame Backend-Codebasis nicht.

Nhost bringt einen mehrteiligen Migrationsprozess zurück

Nhost verbindet Postgres, GraphQL, Auth und Storage ab 25 $. Darin enthalten sind 15 $ Compute-Guthaben und unbegrenzt viele Nutzer [16]. Eine Schemaänderung erzeugt sowohl eine SQL-Migration als auch Hasura-Metadaten in YAML. Laut Nhosts Anleitung zur lokalen Entwicklung werden beide gemeinsam committed und bereitgestellt [17]. Dieser Ablauf ähnelt dem Supabase-Prozess, der in meinen Projekten Probleme verursacht hat.

Encore.ts beginnt vor der Cloud-Rechnung bei 148 $

Encore.ts löst ein anderes Problem: Ich deklariere Infrastruktur in TypeScript, und Encore stellt sie in meinem AWS- oder GCP-Konto bereit. Produktion beginnt bei 49 $ pro Mitglied plus 99 $ pro Cloud-Umgebung. Danach kommen 2,50 $ pro Ressource und die separate AWS-Rechnung hinzu [18]. Die Plattformgebühr beträgt also mindestens 148 $ im Monat.

Für ein Team, das bereits ein eigenes Cloud-Konto verwaltet, kann das sinnvoll sein. Auch die Unterstützung für KI-gestützte Entwicklung ist nützlich. Zu meiner Art, kleine Produkte schnell zu veröffentlichen, passt es nicht.

InsForge ist der Kandidat, den ich beobachte

InsForge kommt meinem gewünschten Ablauf am nächsten, weil es als einzige Alternative auf der Liste speziell für KI-Agenten entwickelt wurde. Die Richtung passt zu meiner Arbeit, doch wegen des Alters und der Finanzierung des Unternehmens würde ich dort heute noch keine Kundendaten speichern.

Als Version 2.0 am 9. März 2026 erschien, beschrieb InsForge das Produkt als Backend für agentische Entwicklung und erklärte, Agenten führten bereits 99 % der Vorgänge auf der Plattform aus [19]. OpenAI nähert sich der Infrastruktur für Agenten von der anderen Seite, und ich gehe durch, was die Agents API übernimmt und welche Kosten bei dir bleiben.

Das Produkt untermauert diesen Anspruch mit Postgres und pgvector, Auth, Storage, Edge Functions, Realtime und einem OpenAI-kompatiblen Gateway für Modelle mehrerer Anbieter [19]. Zeitgesteuerte Functions laufen über pg_cron [20], und der unter Apache 2.0 veröffentlichte Code lässt sich mit Docker selbst hosten [21]. Der Pro-Tarif für 25 $ enthält 100.000 monatlich aktive Nutzer, eine Datenbank mit 8 GB und 10 $ Compute-Guthaben. Kleine, dauerhaft laufende Instanzen beginnen bei 5 $ [22].

InsForge landete teilweise deshalb auf Platz zwei, weil Postgres Migrationen und Row-Level-Security zurückbringt, auch wenn Agenten sie verwalten. Meine größere Sorge ist das Alter des Unternehmens. Crunchbase nennt eine Pre-Seed-Runde über 1,5 Millionen Dollar von MindWorks Capital und Baidu Ventures [23], während MindWorks die Gründung auf 2025 datiert [24].

Convex ist deutlich weiter: Das Unternehmen nahm im November 2025 in einer Runde unter Führung von a16z und mit Spark Capital als Co-Lead 24 Millionen Dollar auf [25]. Im April 2026 meldete Convex fast 10.000 zahlende Teams [26].

Convex, letzte Runde

24 Mio. $

angeführt von a16z, November 2025

zahlende Teams bei Convex

10.000

Firmenangabe, "fast 10.000", April 2026

InsForge, Pre-Seed

1,5 Mio. $

MindWorks Capital und Baidu Ventures, 2025

Wegen dieses Reifeunterschieds würde ich InsForge testen, aber noch keine Kundendaten dorthin verschieben. Die Apache-2.0-Lizenz und die Möglichkeit zum Selbsthosting senken das Risiko eines späteren Versuchs.

Was kostet Convex in der EU? 30 % mehr, mit weniger Inklusivleistung

Ein kostenpflichtiges EU-Deployment von Convex kostet 30 % mehr als sein US-Pendant und erhält nicht die enthaltenen Nutzungsmengen der kostenpflichtigen US-Pläne. Die zentrale Preisseite von Convex nennt für Pro in den USA 25 Millionen enthaltene Function Calls [27]. Im Beitrag zur EU-Region steht dagegen, dass kostenpflichtige EU-Ressourcen 30 % mehr kosten und nach Verbrauch abgerechnet werden [28].

Die EU-Region läuft in AWS eu-west-1 in Irland und steht in jedem Tarif zur Verfügung, auch im kostenlosen. Bei einem europäischen Produkt mit viel Traffic gehört der Preisunterschied in die Kostenrechnung, bevor du die Region auswählst.

Der EU-Aufschlag ist nicht meine einzige Sorge. Free- und Starter-Deployments verwenden die Klasse S16 mit 16 gleichzeitigen Queries und 16 gleichzeitigen Mutations. Professional wechselt zu S256 [29]. Allein der Traffic kann daher ein Upgrade auf 25 $ pro Entwickler erzwingen [27].

Auch Convex Auth ist eingeschränkt. Es befindet sich weiterhin in der Betaphase, und laut Dokumentation ist es noch nicht vollständig und kann sich inkompatibel ändern. Für produktive Auth empfiehlt Convex Clerk, Auth0 oder WorkOS. WorkOS ist für bis zu eine Million Nutzer kostenlos [30].

Das einfache Backend in einem Ordner führt außerdem zu Lock-in. Mein Backend besteht aus Convex Queries und Mutations für ein Dokumentenmodell. Es ist kein SQL-System, an das ich ein übliches Reporting-Tool direkt anschließen kann.

Trotzdem ist der Einstiegspreis gut. Der kostenlose Starter-Tarif unterstützt produktive Anwendungen für bis zu sechs Entwickler und enthält bei US-Deployments eine Million Function Calls [27]. Ich akzeptiere die Kosten von Convex, weil jede gefundene Alternative mehr Entwicklungszeit verlangt. Diese Zeit kostet mich mehr als die Plattformrechnung.

Welche Convex-Alternative solltest du wählen?

Für ein KI-gestütztes Produkt, das schnell veröffentlicht werden soll, würde ich Convex wählen. Appwrite würde ich testen, wenn Auth für Hunderttausende Nutzer zum wichtigsten Engpass wird. Mit einer pauschalen Organisationsgebühr von 25 $ wird Appwrite bei einem wachsenden Team attraktiver als die Abrechnung von Convex pro Entwickler [5].

InsForge würde ich Mitte 2027 erneut prüfen. Eine weitere Finanzierungsrunde und benannte produktive Kunden könnten meine Entscheidung ändern. Weil InsForge Self-Hosting erlaubt, ist ein späterer Test schon heute weniger riskant.

Der praktische Test ist einfach: Öffne das Repository nach einer Woche und prüfe, ob dir ein Ordner zeigt, wo die Backend-Logik liegt. Wenn das der Fall ist, kann ein KI-Agent eine Änderung eher vollständig umsetzen, ohne einen separaten Konfigurationsschritt zu übersehen. Für alles außerhalb des Backend-Ordners verlasse ich mich auf eine Karte aus vier Ebenen, die meine Coding-Agents zu den aktuellen Fakten führt.

In meinem letzten Artikel habe ich untersucht, wie viel Entscheidungsspielraum ein KI-Modell bekommen sollte. Bei der Wahl eines Backends stellt sich eine verwandte Frage: Wie viele getrennte Teile muss das Modell verstehen? Convex bleibt meine Wahl, weil es diese Zahl niedrig hält.