Warum ich Convex für passende Projekte wähle
Reaktive Daten, TypeScript und klare Backend-Funktionen: Was mich an Convex überzeugt und wann ich weiterhin PostgreSQL wählen würde.
Bei einem neuen Projekt interessiert mich am Backend zuerst eine ziemlich einfache Frage: Wie gut lässt sich damit das Produkt bauen, das ich im Kopf habe?
Ich arbeite gerne mit React, Next.js, Bun, Prisma und PostgreSQL. Gleichzeitig finde ich Convex für bestimmte Anwendungen sehr überzeugend. Gerade wenn mehrere Menschen mit denselben Daten arbeiten oder im Hintergrund länger laufende Aufgaben stattfinden, passt das Modell gut zu der Oberfläche, die ich entwickeln möchte.
Das ist meine Einordnung auf Basis der Dokumentation vom September 2026. Eine Entscheidung für Convex bedeutet für mich dabei immer eine Entscheidung für ein konkretes Projekt.
Ein Backend, das zur Oberfläche passt
Convex unterscheidet drei zentrale Funktionen: Queries lesen Daten und lassen sich abonnieren, Mutations ändern Daten innerhalb einer Transaktion, Actions sprechen externe Dienste an. Diese Aufteilung ist im Überblick zu Convex-Funktionen beschrieben.
Mir gefällt daran die klare Frage, die ich beim Schreiben einer Funktion beantworten muss: Lese ich etwas, ändere ich einen fachlichen Zustand oder verlasse ich das eigene System?
Nehmen wir eine Anwendung, in der jemand Dokumente hochlädt und anschließend deren Verarbeitung beobachtet. Ich möchte den Status nicht an fünf Stellen manuell nachladen. Für mich gehört die Anzeige des aktuellen Zustands zur eigentlichen Funktion. Eine reaktive Query passt deshalb gut zu diesem Ablauf.
Das macht auch das Entwerfen der Oberfläche angenehmer. Die Liste kann sich auf Zustände wie „wartet“, „wird verarbeitet“ und „fertig“ konzentrieren. Die Frage, wann Daten erneut abgefragt werden, soll möglichst wenig eigene Produktlogik benötigen.
Die Grenze nach außen bleibt wichtig
Ein externer Aufruf kann erfolgreich sein, obwohl die Antwort unterwegs verloren geht. Convex wiederholt fehlgeschlagene Actions deshalb nicht automatisch wie reine Datenbankoperationen. Die Dokumentation zu Actions erläutert diese Grenze ausdrücklich.
Für mein Dokumentbeispiel würde ich deshalb zuerst einen Auftrag mit eindeutiger Kennung speichern. Danach kann eine Action den externen Dienst ansprechen und das Ergebnis über eine Mutation übernehmen. Wenn der Dienst Idempotenzschlüssel unterstützt, würde ich dieselbe Auftragskennung verwenden.
Idempotent bedeutet hier: Derselbe Auftrag darf bei einer Wiederholung nicht versehentlich zweimal ausgeführt werden. Zusätzlich brauche ich einen nachvollziehbaren Fehlerstatus und eine Regel dafür, wann ein erneuter Versuch sinnvoll ist. Diese Entscheidungen nehme ich mir mit einer Backend-Plattform nicht ab.
Anmeldung ist erst der Anfang
Über ctx.auth.getUserIdentity() kann eine Backend-Funktion die Identität des angemeldeten Nutzers abfragen. Die Auth-Dokumentation zeigt den vorgesehenen Zugriff.
Meine eigentliche Berechtigungsprüfung beginnt danach. Gehört das Dokument zum aktuellen Workspace? Darf diese Person nur lesen oder auch löschen? Ist die Mitgliedschaft noch aktiv?
Ich würde solche Prüfungen in gemeinsam verwendeten Helfern bündeln und in jeder öffentlich erreichbaren Funktion erzwingen. Ein ausgeblendeter Button im Frontend kann die Bedienung erklären, aber niemals die Entscheidung im Backend ersetzen. Gerade in Anwendungen mit mehreren Organisationen möchte ich diese Grenze im Code sofort erkennen können.
Warum PostgreSQL trotzdem einen festen Platz behält
Convex speichert Dokumente und bietet ein relationales Datenmodell über Referenzen. Gelesen und geschrieben wird über JavaScript-Funktionen; es ist kein PostgreSQL-Backend mit einer anderen Oberfläche. Das beschreibt die Datenbankübersicht.
Wenn ein Projekt bereits stark auf SQL, bestehende Datenbanken und Auswertungswerkzeuge ausgerichtet ist, würde ich einen Wechsel besonders kritisch prüfen. Für mich zählen auch die Erfahrung des Teams, Datenexporte, Betriebsanforderungen und die Kosten unter realistischer Nutzung.
Ein Prototyp hilft bei dieser Entscheidung mehr als ein Vergleich von Featurelisten. Ich würde einen vollständigen Ablauf bauen: anmelden, einen Datensatz anlegen, Berechtigungen prüfen, einen Hintergrundauftrag starten und einen Fehler bewusst auslösen. Erst dabei sehe ich, ob das Modell zum Projekt passt.
Meine Auswahlregel
Ich wähle Convex gerne, wenn eine interaktive Anwendung von reaktiven Daten profitiert und ich ihre Backend-Logik konsequent in TypeScript beschreiben möchte. PostgreSQL bleibt für mich eine ebenso bewusste Option, wenn vorhandene Systeme und SQL den Alltag bestimmen.
Am Ende möchte ich weniger Zeit damit verbringen, Zustände zwischen Oberfläche und Backend zusammenzuhalten. Genau an dieser Stelle finde ich Convex interessant.