Amazon Redshift relève la limite des chaînes SUPER de 65 535 à 16 millions d’octets, mais seulement après activation d’un paramètre, avec redémarrage des clusters provisionnés, colonnes VARCHAR(MAX) inchangées et sans retour à la valeur par défaut

Le 6 novembre 2026, AWS a annoncé qu’Amazon Redshift peut désormais stocker dans le type de données SUPER des chaînes individuelles allant jusqu’à 16 millions d’octets, contre 65 535 octets auparavant. Cela s’applique aux données chargées depuis des fichiers JSON, PARQUET, TEXT et CSV et aux données produites par des tâches d’extraction, de chargement et de transformation (ELT), et AWS indique que la fonction est disponible dans toutes les régions AWS où Redshift est proposé, y compris les régions AWS GovCloud (US). La condition essentielle figure dans le premier paragraphe de l’annonce : il faut l’activer explicitement par un paramètre de base de données. Sans cette activation, rien ne change.

L’usage visé concerne les données semi-structurées qu’il fallait auparavant découper ou tronquer avant le chargement. AWS cite des documents longs comme des conditions générales et des contrats, et son article de blog associé ajoute des catalogues de produits détaillés, des journaux d’applications complets et des historiques d’interactions avec les clients. Une fois ces données dans Redshift, on peut les interroger en SQL, les explorer avec le langage PartiQL et les transformer avec des fonctions de chaîne. AWS dit que des fonctions comme JSON_PARSE, CONCAT et LISTAGG peuvent maintenant prendre des chaînes en entrée et renvoyer des chaînes en sortie allant jusqu’à 16 millions d’octets.

La documentation de Redshift explique ce que fait l’activation et où s’arrête la limite. Le paramètre est enable_large_strings_opt_in, avec les valeurs Yes, No ou non défini, et « non défini » conserve le comportement existant du cluster. Réglé sur Yes, les chaînes individuelles de SUPER peuvent atteindre 16 000 000 d’octets, les fonctions de chaîne en mémoire peuvent traiter des valeurs VARCHAR de cette taille, et VARCHAR(MAX) se résout en VARCHAR(16000000) dans les contextes d’expression comme les expressions CAST, les vues, les fonctions définies par l’utilisateur et les procédures stockées. Cela n’élargit pas les colonnes stockées : CREATE TABLE avec VARCHAR(MAX) crée toujours une colonne VARCHAR(65535). La grande taille vit donc dans les valeurs SUPER et en mémoire, pas dans les colonnes VARCHAR ordinaires. Le patch 206 ou ultérieur est requis. Les vues, UDF et procédures stockées existantes restent limitées à 65 535 octets jusqu’à leur recréation ; les colonnes VARCHAR ordinaires ne s’élargissent pas. L’ancienne limite de 16 Mo pour un objet SUPER entier est distincte des 16 000 000 d’octets pour une chaîne unique.

Plusieurs détails d’exploitation comptent avant d’activer l’option. Un cluster provisionné doit être redémarré pour appliquer le paramètre, tandis qu’Amazon Redshift Serverless utilise un paramètre de configuration du groupe de travail au lieu d’un groupe de paramètres. Une fois le paramètre réglé sur Yes ou No, on ne peut plus le ramener à la valeur par défaut, et une réinitialisation par ResetClusterParameterGroup conserve la valeur d’origine. La commande `SELECT is_large_string_enabled();` indique l’état actuel. L’exemple du blog associé charge de gros documents JSON avec COPY en utilisant l’option `FORMAT JSON 'noshred'` pour que chaque document reste une seule valeur SUPER. Le blog présente trois améliorations : les grandes chaînes, les opérations de chaîne en mémoire sans troncature, et SUPER dans les bases insensibles à la casse, avec un réglage `enable_case_sensitive_super_attribute` pour les noms d’attributs en camelCase. Nous n’avons rien exécuté de tout cela. En partage de données, les entrepôts producteur et consommateur doivent avoir le même réglage enable_large_strings_opt_in. L’impossibilité de revenir à la valeur non définie n’empêche pas de choisir explicitement No.

L’annonce et la documentation ne donnent ni temps de chargement, ni mémoire, ni latence près de 16 millions d’octets. Les sources examinées ne précisent pas l’effet sur les tarifs ; il faut les vérifier séparément. Le blog évoque d’anciens débordements sur disque sans mesure. La compatibilité concrète des outils clients, pilotes et exports avec de très grandes valeurs n’a pas été testée et doit être vérifiée outil par outil ; les limites des objets existants et du partage de données sont, elles, explicites dans le blog.

Notre lecture : c’est un changement utile et étroit qui lève une limite stricte pour ceux qui gardent de gros documents JSON dans SUPER, et le principe de l’activation volontaire protège les charges existantes. C’est aussi un réglage qu’on ne peut plus ramener à l’état non défini une fois Yes ou No choisi, et il ne modifie pas les définitions de tables. Une équipe devrait l’essayer d’abord sur un cluster hors production, fenêtre de redémarrage comprise, vérifier que ses outils clients et ses requêtes en aval supportent de très grandes valeurs, puis seulement décider d’activer le paramètre en production.