|
07.09.2026
13:00 Uhr
|
Appwrite 2.0 bringt native PostgreSQL- und MySQL-Datenbanken, S3-kompatible Storage-API und OAuth-2.1-Server für die BaaS-Plattform.
Appwrite 2.0 baut die Open-Source-Backend-Plattform grundlegend um. Die neue Hauptversion bringt unter anderem native PostgreSQL- und MySQL-Datenbanken, eine S3-kompatible Storage-API sowie einen OAuth-2.1- und OpenID-Connect-Server. Parallel führt Appwrite mit DocumentsDB für schemafreie JSON-Dokumente und VectorsDB für Vektordaten zwei weitere Datenbanksysteme ein. Bestehende Cloud-Projekte sollen ohne Migration weiterlaufen; für selbst betriebene Installationen aus der 1.9-Reihe ist dagegen ein Upgrade einschließlich Migrationen vorgesehen.
Appwrite ist eine quelloffene Backend-as-a-Service-Plattform (BaaS). Sie bündelt Dienste wie Authentifizierung, Datenbanken, Dateispeicher, Serverfunktionen, Messaging und Realtime-Schnittstellen hinter APIs und SDKs. Nutzer können die Plattform selbst betreiben oder die Cloud-Variante verwenden. Einen Überblick über die Produktbereiche bietet die Appwrite-Dokumentation.
Version 2.0 erweitert vor allem die Datenbankfunktionen. Neben der bisherigen, über Appwrites APIs verwalteten Datenhaltung stehen nun native PostgreSQL- und MySQL-Instanzen zur Verfügung. Anwendungen verbinden sich mit diesen Datenbanken direkt über die jeweiligen Standardprotokolle, also etwa mit psql, dem MySQL-Client, einem Treiber oder einem eigenen ORM. Appwrite übernimmt dabei laut Ankündigung die Bereitstellung und den Betrieb, vermittelt aber nicht zwischen Anwendung und Datenbank.
Die nativen PostgreSQL- und MySQL-Datenbanken bietet Appwrite als dedizierte Cloud-Dienste für kostenpflichtige Tarife an. Bei selbst betriebenen Neuinstallationen setzt Appwrite dagegen standardmäßig auf PostgreSQL; MariaDB und MongoDB bleiben unterstützt.
Der direkte Zugriff auf die Datenbanken soll vor allem Nutzer ansprechen, die Appwrite etwa für Authentifizierung und Hosting verwenden, bei der Datenbank aber etablierte SQL-Werkzeuge, eigene Migrationen oder vorhandene Anwendungen weiter einsetzen wollen. Native Datenbanken sind als dedizierte Angebote vorgesehen. PostgreSQL 18 ist standardmäßig vorgesehen, alternativ steht PostgreSQL 17 bereit; bei MySQL setzt Appwrite auf 8.4 oder 8.0.
Parallel führt Appwrite zwei weitere verwaltete Datenbanktypen ein. DocumentsDB speichert JSON-Dokumente ohne festes Schema. Zwei Dokumente einer Collection dürfen somit unterschiedliche Felder enthalten; neue Eigenschaften erfordern keine Schema-Migration. Berechtigungen auf Dokumentebene, Abfragen, Sortierung und Seitennavigation bleiben über die Appwrite-SDKs verfügbar. Das eignet sich beispielsweise für Daten aus externen APIs oder Inhalte, deren Struktur sich häufig ändert.
VectorsDB richtet sich an KI-gestützte Suche und Retrieval-Anwendungen. Jede Collection erhält eine feste Vektordimension; zu jedem Eintrag lassen sich Metadaten speichern. Für Ähnlichkeitssuchen verwendet Appwrite einen HNSW-Index und unterstützt Kosinusähnlichkeit, Skalarprodukt sowie euklidische Distanz. Eine integrierte Embeddings-API kann Text in Vektoren umwandeln, ohne dass Entwickler dafür zwingend einen separaten Embedding-Dienst betreiben müssen.
Appwrite Storage erhält eine S3-kompatible Schnittstelle. Sie verwendet AWS Signature Version 4 und bildet S3-Operationen auf vorhandene Appwrite-Buckets und Dateien ab. Damit sollen sich beispielsweise AWS CLI, AWS SDKs oder S3-fähige Werkzeuge wie rclone gegen Appwrite einsetzen lassen. Die native Storage-API bleibt parallel nutzbar: Dateien, die über S3 hochgeladen wurden, sollen also auch in der Console erscheinen – und umgekehrt. Details zu Storage und der S3-API beschreibt die Appwrite-Produktdokumentation.
Neu ist außerdem ein OAuth-2.1-Server mit OpenID Connect. Ein Appwrite-Projekt kann damit selbst als Identity Provider auftreten. Fremde Anwendungen registrieren sich als Clients und können Nutzer etwa über einen „Sign in with …“-Flow anmelden oder begrenzt auf Projektressourcen zugreifen. Appwrite nennt unter anderem PKCE, Token-Introspection und -Widerruf, JWT-Zugriffstoken, Device Authorization Grant sowie dynamische Client-Registrierung als unterstützte Bausteine.
Für Plattformbetreiber ergänzt Appwrite das mit einer Partnerschnittstelle. Über sie lassen sich OAuth-Anwendungen, Weiterleitungs-URLs, Secrets und Branding verwalten. Denkbar sind damit etwa selbst entwickelte Marktplätze, auf denen Organisationen Erweiterungen installieren, die anschließend mit delegierten Berechtigungen auf Appwrite-Ressourcen zugreifen.
Mit Console IV erhält die Verwaltungsoberfläche einen Neuaufbau auf Basis von TanStack. Appwrite fasst darin Console, Dokumentation, Blog und Changelog zusammen. Hinzu kommen ein Terminal, das die Appwrite-CLI mit bereits gesetztem Projekt- und Sitzungskontext im Browser ausführt, sowie der Explorer. Letzterer lädt die OpenAPI-Beschreibung eines Projekts, erzeugt daraus Eingabeformulare und kann API-Aufrufe direkt aus der Console absenden.
In der Cloud führt Appwrite ferner Domains und Firewall ein. Domains bündelt Domainregistrierung, DNS-Verwaltung und TLS-Zertifikate auf Organisationsebene. Die Firewall erlaubt Regeln vor API, Functions und Sites. Sie können nach IP-Adresse, Hostname, Pfad, HTTP-Methode, Headern, Query-Parametern, User-Agent oder Standort filtern und Anfragen etwa ablehnen, umleiten, begrenzen oder mit einer Challenge versehen. Vor dem Speichern zeigt Appwrite an, wie viele jüngere Anfragen von einer Regel betroffen wären. Domains und Firewall bleiben laut Anbieter Cloud-exklusiv.
Unter dem Namen Hyperloop B ersetzt Appwrite den bisherigen Ausführungsunterbau durch ein Coroutine-Modell auf Basis von Swoole. Ein Prozess kann dabei mehrere I/O-lastige Anfragen bedienen, indem er bei wartenden Ein- und Ausgabeoperationen andere Tasks ausführt. Nach Angaben von Appwrite sinkt dadurch insbesondere der Speicherbedarf von Realtime-Ereignissen: Das System kodiert ein Dokument einmal pro Event statt einmal pro Abonnent.
VectorsDB und DocumentsDB sind bei Self-Hosting zunächst deaktiviert, da dafür zusätzliche Datenbank-Engines nötig sind. Die Release Notes nennen außerdem eine optionale Embedding-Komponente, die wegen ihres Ressourcenbedarfs standardmäßig nicht startet. Die vollständige Liste der Konfigurationsoptionen und Bugfixes steht in den Release Notes zu Appwrite 2.0.
Beim Upgrade einer selbst betriebenen 1.9-Installation sollen vorhandene Daten auf dem bisherigen Datenbank-Backend verbleiben. Appwrite verweist dennoch auf ein versionsgesteuertes Upgrade samt Migrationen und empfiehlt vorher ein Backup. In der Cloud sollen bestehende Projekte dagegen ohne verpflichtende Migration weiterarbeiten.
(fo)