Appwrite, die quelloffene Backend-as-a-Service-Plattform (BaaS), mit der Entwickler Anwendungen um Authentifizierung, Datenbanken, Speicher und Serverfunktionen ergänzen, ist in Version 2.0 erschienen – der größte Umbau in der Geschichte des Projekts.
Das zentrale Novum betrifft die Datenhaltung. Neben den Dokumentenspeichern, die Appwrite seit Jahren hinter eigenen APIs verwaltet, bietet 2.0 nun native PostgreSQL- und MySQL-Datenbanken an, auf die Anwendungen direkt über die Standardprotokolle zugreifen – per psql, MySQL-Client, Treiber oder eigenem ORM. Appwrite stellt die Instanzen bereit und betreibt sie, vermittelt aber nicht mehr zwischen Anwendung und Datenbank. Gedacht ist das vor allem für Teams, die Appwrite für Authentifizierung und Hosting nutzen, bei der Datenbank aber auf etablierte SQL-Werkzeuge, eigene Migrationen oder vorhandene Anwendungen setzen wollen. Die nativen Datenbanken gibt es als dedizierte, kostenpflichtige Cloud-Dienste; bei selbst betriebenen Neuinstallationen ist PostgreSQL nun die Standarddatenbank, MariaDB und MongoDB bleiben unterstützt. PostgreSQL 18 ist die Standardversion, alternativ steht 17 bereit; bei MySQL handelt es sich um 8.4 oder 8.0.
Dazu führt Appwrite zwei neue verwaltete Datenbanktypen ein. DocumentsDB speichert schemafreie JSON-Dokumente – zwei Dokumente einer Collection dürfen unterschiedliche Felder haben, neue Eigenschaften brauchen keine Schema-Migration – und behält Dokumentberechtigungen, Abfragen, Sortierung und Seitennavigation über die Appwrite-SDKs. VectorsDB richtet sich an KI-Suche und Retrieval: Jede Collection bekommt eine feste Vektordimension, pro Eintrag lassen sich Metadaten ablegen, und die Ähnlichkeitssuche läuft über einen HNSW-Index mit Kosinusähnlichkeit, Skalarprodukt und euklidischer Distanz. Eine integrierte Embeddings-API kann Text in Vektoren umwandeln, ohne dass dafür ein separater Embedding-Dienst betrieben werden muss.
Der Storage erhält eine S3-kompatible Schnittstelle auf Basis von AWS Signature Version 4, die S3-Operationen auf vorhandene Appwrite-Buckets und Dateien abbildet – AWS-CLI, AWS-SDKs und S3-fähige Werkzeuge wie rclone lassen sich damit direkt auf Appwrite richten. Die native Storage-API bleibt parallel nutzbar; Dateien, die über S3 hochgeladen wurden, erscheinen auch in der Console – und umgekehrt.
Für Identitäten liefert Appwrite 2.0 einen OAuth-2.1-Server mit OpenID Connect, der ein Projekt zum eigenen Identity Provider macht. Fremde Anwendungen registrieren sich als Clients und können Nutzer etwa über einen „Sign in with Appwrite“-Flow anmelden oder mit begrenzten Rechten auf Projektressourcen zugreifen; unterstützt werden unter anderem PKCE, Token-Introspection und -Widerruf, JWT-Zugriffstokens, der Device Authorization Grant und dynamische Client-Registrierung. Eine Partnerschnittstelle erlaubt Plattformbetreibern, OAuth-Anwendungen, Redirect-URLs, Secrets und Branding zu verwalten – etwa für Marktplätze, auf denen Organisationen Erweiterungen installieren, die anschließend mit delegierten Rechten auf Appwrite-Ressourcen zugreifen.
Auch die Verwaltungsoberfläche ist neu: Console IV, auf Basis von TanStack neu gebaut, vereint Konsole, Dokumentation, Blog und Changelog und bringt ein Terminal mit, das die Appwrite-CLI mit bereits gesetztem Projekt- und Sitzungskontext im Browser ausführt. Der Explorer lädt die OpenAPI-Beschreibung eines Projekts, erzeugt daraus Eingabeformulare und schickt API-Aufrufe direkt aus der Console ab. In der Cloud ergänzt Appwrite Domains (Domain-Registrierung, DNS und TLS-Zertifikate auf Organisationsebene) und eine Firewall, die Anfragen an APIs, Functions und Sites nach IP-Adresse, Hostname, Pfad, HTTP-Methode, Headern, Query-Parametern, User-Agent oder Standort filtert – mit Optionen zum Ablehnen, Umleiten, Begrenzen oder Versehen mit einer Challenge und einer Vorschau, wie viele jüngere Anfragen eine Regel beträfe. Beides bleibt Cloud-exklusiv.
Unter der Haube ersetzt „Hyperloop B“ den bisherigen Ausführungsunterbau durch ein Coroutine-Modell auf Basis von Swoole. Ein Prozess kann mehrere I/O-lastige Anfragen bedienen, indem er bei wartenden Ein- und Ausgabeoperationen andere Tasks ausführt. Laut Appwrite sinkt dadurch vor allem der Speicherbedarf von Realtime-Ereignissen – ein Dokument wird einmal pro Event statt einmal pro Abonnent kodiert.
Selbstbetreiber erwartet der größte Einschnitt. DocumentsDB und VectorsDB sind beim Self-Hosting zunächst deaktiviert, weil dafür zusätzliche Datenbank-Engines nötig sind; eine optionale Embedding-Komponente startet wegen ihres Ressourcenbedarfs standardmäßig nicht. Beim Upgrade einer selbst betriebenen Installation aus der 1.9-Reihe handelt es sich um einen versionsgesteuerten Prozess mit Migrationen und empfohlenem Backup; die vorhandenen Daten bleiben auf dem bisherigen Datenbank-Backend. In der Cloud laufen bestehende Projekte dagegen ohne verpflichtende Migration weiter.
