Weaviate stuft GraphQL-API als veraltet ein, Abschaltung in der Cloud zum 1. Mai 2027

26. Oktober 2026Quelle: Weaviate

Weaviate hat GraphQL, die erste Abfrage-API des Unternehmens, als veraltet eingestuft und schaltet sie in Weaviate Cloud am 1. Mai 2027 ab. Laut Anbieter geht zum Stichtag der Einstufung am 26. Oktober 2026 nichts kaputt, und Nutzern stehen gRPC-basierte Clients sowie eine REST Search API als Alternativen zur Verfügung.

Das Wichtigste in Kürze

Weaviate hat seine GraphQL-API am 26. Oktober 2026 als veraltet eingestuft, an diesem Tag geht nichts kaputt.
Weaviate Cloud schaltet GraphQL am 1. Dezember 2026 auf ungenutzten Clustern und am 1. Mai 2027 auf allen Clustern ab.
Als Ersatz empfohlen werden gRPC-basierte Clients, der TypeScript-Web-Client und die REST Search API, die sich in der Preview-Phase befindet.
Selbst gehostete Versionen, die vor dem 1. Mai 2027 erscheinen, behalten GraphQL, das erste Minor-Release danach deaktiviert es standardmäßig.
Nutzer können mit deaktiviertem GraphQL testen, über die Einstellung DISABLE_GRAPHQL oder per Anfrage beim Cloud-Support.

Zeitplan für Weaviate Cloud und selbst gehostete Installationen

Weaviate zufolge gilt die GraphQL-API ab dem 26. Oktober 2026 als veraltet, bestehende Cluster laufen aber vorerst weiter. In Weaviate Cloud wird GraphQL in zwei Schritten abgeschaltet. Am 1. Dezember 2026 wird es auf Clustern deaktiviert, die GraphQL in den vergangenen 30 Tagen nicht genutzt haben. Am 1. Mai 2027, dem Ende der Laufzeit (End of Life) von GraphQL in Weaviate Cloud, wird es auf allen übrigen Clustern abgeschaltet.

Neue Weaviate-Cloud-Cluster werden laut Unternehmen bereits ohne GraphQL angelegt. Weaviate informiert alle Weaviate-Cloud-Kunden per E-Mail, damit sie wissen, ob ihre Cluster betroffen sind.

Für selbst gehostete Installationen gilt: Jede Weaviate-Version, die vor dem 1. Mai 2027 erscheint, behält eine funktionierende GraphQL-API. Das erste Minor-Release nach diesem Datum deaktiviert sie standardmäßig, sie lässt sich aber wieder einschalten. In einem späteren Release wird sie entfernt, einen Termin dafür hat Weaviate noch nicht festgelegt.

Warum Weaviate sich von GraphQL abwendet

Weaviate will nach eigenen Angaben eine einzige moderne Abfrage-API anbieten und nennt dafür mehrere Gründe.

Geschwindigkeit: gRPC überträgt binäre Protocol Buffers über HTTP/2, sodass Abfragen laut Unternehmen weniger Bandbreite benötigen und schneller antworten als JSON über HTTP.
Klare Verträge: Typisierte Nachrichten liefern den Clients typisierte Ergebnisse und generierte Request-Objekte. Fehler kommen als echte Statuscodes an statt als HTTP 200 mit einem Errors-Array, und Metadaten sind ein Feld des Ergebnisses statt eines separaten _additional-Blocks.
Sicherheit: Die GraphQL-Introspektion verlangt Leseberechtigung auf jeder Collection, was laut Weaviate nicht zur rollenbasierten Zugriffskontrolle (RBAC) mit Berechtigungen pro Collection passt. Die gRPC- und die REST-API prüfen genau die Collection, die abgefragt wird.
Moderne Abfrageerstellung: Weaviate verweist darauf, dass die meisten Abfragen inzwischen von Client-Bibliotheken, Frameworks und Agenten erzeugt werden. Dafür eignen sich ein kompaktes Binärprotokoll und eine schlichte JSON-API besser als eine von Hand geschriebene Abfragesprache.

Die Pflege nur einer API bedeutet zudem, dass jede Suchfunktion nur einmal entwickelt, getestet und dokumentiert wird. Dadurch kann das Unternehmen Verbesserungen nach eigenen Angaben schneller ausliefern.

Wer betroffen ist und was stattdessen zu nutzen ist

Die Änderung betrifft nur Nutzer, die Abfragen per GraphQL an Weaviate senden. Dazu zählt Code, der /v1/graphql direkt aufruft, Raw-Helfer wie graphql_raw_query() in Python verwendet oder GraphQL-Abfragen aus Browser-Code absetzt. Auch ältere Clients sind betroffen: die Python-v3-API (weaviate.Client), weaviate-ts-client v2, der Java-Client v5 und früher sowie der Go-Client. Der stabile Go-v5-Client fragt weiterhin über GraphQL ab, während der v6-Client gRPC nutzt und ein Release Candidate ist. Ebenfalls betroffen sind No-Code- und BI-Tools, die GraphQL senden. Nutzer von Frameworks wie LangChain oder LlamaIndex sollten die offizielle Weaviate-Integration auf Basis eines aktuellen Clients verwenden, da ein Community-Paket unter Umständen noch GraphQL sendet.

Wer über einen aktuellen Python-, TypeScript-, Java- oder C#-Client sucht, ist laut Weaviate höchstwahrscheinlich nicht betroffen. Das Unternehmen empfiehlt diese Clients, die über gRPC suchen. Für Browser und Edge-Runtimes, die keine native gRPC-Verbindung öffnen können, nutzt der TypeScript-Web-Client (@weaviate/web) gRPC-Web und ist ab sofort mit derselben API wie der Node-Client verfügbar.

Für Stacks, in denen kein Client laufen kann, bietet eine REST Search API schlichte JSON-Endpunkte für Suche und Aggregation. Sie befindet sich in der Preview-Phase und ist eine Teilmenge dessen, was GraphQL bietet. Weaviate räumt ein, dass es für einige wenige GraphQL-exklusive Funktionen derzeit kein Äquivalent gibt, und bittet Nutzer, die darauf angewiesen sind, den Support zu kontaktieren.

So gelingt die Migration und was sie für Nutzer bedeutet

Weaviate empfiehlt vier Schritte: GraphQL-Aufrufe in Code, Proxys und Tools aufspüren, einen Ersatzpfad wählen, die Abfragen anhand des Migrationsleitfadens umstellen und die Anwendung mit deaktiviertem GraphQL prüfen. Der Leitfaden des Unternehmens enthält eine Entscheidungstabelle und ein Beispiel für eine Near-Text-Suche auf einer Movie-Collection, formuliert in GraphQL, im Python-Client, im TypeScript-Web-Client und in der REST Search API.

Selbst gehostete Nutzer können schon jetzt testen, indem sie die Umgebungsvariable DISABLE_GRAPHQL auf true setzen und neu starten oder den Runtime-Config-Schlüssel disable_graphql verwenden. Bei deaktiviertem GraphQL liefern POST /v1/graphql und POST /v1/graphql/batch den HTTP-Status 422. In Weaviate Cloud können Nutzer den Support bitten, GraphQL zu Testzwecken auf einem Cluster ihrer Wahl abzuschalten.

Mit sechs Monaten zwischen Einstufung als veraltet und Ende der Laufzeit in Weaviate Cloud können Teams die Umstellung an ihren eigenen Releases ausrichten. Support gibt es über das Support-Portal oder unter [email protected].