Amazon Redshift hebt die SUPER-Stringgrenze von 65.535 auf 16 Millionen Byte, aber erst nach Aktivierung per Parameter, mit Neustart bereitgestellter Cluster, unveränderten VARCHAR(MAX)-Tabellenspalten und ohne Rückweg zum Standard

Am 6. November 2026 hat AWS angekündigt, dass Amazon Redshift im Datentyp SUPER nun einzelne Zeichenketten von bis zu 16 Millionen Byte speichern kann, bisher waren es 65.535 Byte. Das gilt für Daten, die aus JSON-, PARQUET-, TEXT- und CSV-Dateien geladen werden, und für Daten aus ELT-Jobs (Extract, Load, Transform), und AWS sagt, es sei in allen AWS-Regionen verfügbar, in denen Redshift läuft, einschließlich der AWS-GovCloud-(US)-Regionen. Die entscheidende Bedingung steht im ersten Absatz der Ankündigung: Man muss die Funktion über einen Datenbankparameter aktivieren. Ohne diese Aktivierung ändert sich nichts.

Der Anwendungsfall sind halbstrukturierte Daten, die früher vor dem Laden zerlegt oder gekürzt werden mussten. AWS nennt lange Dokumente wie Geschäftsbedingungen und Verträge, und der begleitende Blogbeitrag ergänzt detaillierte Produktkataloge, vollständige Anwendungsprotokolle und Kundenhistorien. Liegen solche Daten in Redshift, lassen sie sich mit SQL abfragen, mit der Sprache PartiQL erkunden und mit String-Funktionen umwandeln. AWS sagt, Funktionen wie JSON_PARSE, CONCAT und LISTAGG könnten nun Eingabezeichenketten annehmen und Ausgabezeichenketten von bis zu 16 Millionen Byte zurückgeben.

Die Redshift-Dokumentation erklärt, was die Aktivierung bewirkt und wo die Grenze endet. Der Parameter heißt enable_large_strings_opt_in mit den Werten Yes, No oder nicht gesetzt, und „nicht gesetzt“ bewahrt das bestehende Verhalten des Clusters. Bei Yes können einzelne Zeichenketten in SUPER 16.000.000 Byte erreichen, String-Funktionen im Arbeitsspeicher können VARCHAR-Werte dieser Größe verarbeiten, und VARCHAR(MAX) wird in Ausdruckskontexten wie CAST-Ausdrücken, Sichten, benutzerdefinierten Funktionen und gespeicherten Prozeduren zu VARCHAR(16000000) aufgelöst. Gespeicherte Spalten werden dadurch nicht breiter: CREATE TABLE mit VARCHAR(MAX) erzeugt weiterhin eine Spalte VARCHAR(65535). Die große Größe gilt also für SUPER-Werte und im Arbeitsspeicher, nicht für gewöhnliche VARCHAR-Spalten. Patch 206 oder neuer ist nötig. Bereits vorhandene Sichten, UDFs und gespeicherte Prozeduren bleiben bis zur Neuerstellung auf 65.535 Byte begrenzt; gewöhnliche VARCHAR-Spalten werden nicht breiter. Die bestehende 16-MB-Grenze für ein ganzes SUPER-Objekt ist von der neuen Grenze von 16.000.000 Byte je Zeichenkette zu unterscheiden.

Vor dem Einschalten sind mehrere betriebliche Details wichtig. Ein bereitgestellter Cluster muss neu gestartet werden, damit der Parameter wirkt, während Amazon Redshift Serverless statt einer Parametergruppe einen Konfigurationsparameter der Arbeitsgruppe verwendet. Nachdem man den Parameter auf Yes oder No gesetzt hat, lässt er sich nicht mehr auf den Standard zurücksetzen, und ein Zurücksetzen über ResetClusterParameterGroup behält den ursprünglichen Wert. Der Befehl `SELECT is_large_string_enabled();` zeigt den aktuellen Zustand. Das Beispiel im begleitenden Blog lädt große JSON-Dokumente mit COPY unter Verwendung der Option `FORMAT JSON 'noshred'`, damit jedes Dokument ein einzelner SUPER-Wert bleibt. Der Blog nennt drei Verbesserungen: große Zeichenketten, String-Operationen im Arbeitsspeicher ohne Kürzung und SUPER in Datenbanken ohne Groß- und Kleinschreibung, dazu eine Einstellung `enable_case_sensitive_super_attribute` für Attributnamen in camelCase. Wir haben nichts davon ausgeführt. Beim Data Sharing müssen Produzenten- und Konsumenten-Warehouse enable_large_strings_opt_in gleich einstellen. Nicht auf „ungesetzt“ zurücksetzen zu können heißt nicht, dass No nicht ausdrücklich wählbar wäre.

Ankündigung und Dokumentation nennen keine Ladezeit, Speichernutzung oder Abfragelatenz bei Zeichenketten nahe 16 Millionen Byte. Die geprüften Quellen erläutern keine Preiswirkung; Preise sind gesondert zu prüfen. Der Blog erwähnt frühere Leistungseinbußen durch Auslagerungen, zeigt aber keine Messung. Konkrete Client-Werkzeuge, Treiber und Exporte wurden mit sehr großen Werten nicht getestet und sind einzeln zu prüfen; die Grenzen bestehender Objekte und des Data Sharing sind im Blog ausdrücklich dokumentiert.

Unsere Einschätzung: Das ist eine nützliche, enge Änderung, die eine harte Grenze für alle aufhebt, die große JSON-Dokumente in SUPER halten, und die Opt-in-Gestaltung schützt bestehende Lasten. Außerdem lässt sich die Einstellung nach der Wahl von Yes oder No nicht mehr auf den ungesetzten Standard zurückführen, und sie ändert keine Tabellendefinitionen. Ein Team sollte sie zuerst auf einem Nicht-Produktionscluster ausprobieren, das Neustartfenster eingeschlossen, prüfen, ob Client-Werkzeuge und nachgelagerte Abfragen sehr große Werte verkraften, und erst dann entscheiden, ob es den Parameter in der Produktion setzt.