Amazon RedshiftがSUPER文字列の上限を65,535バイトから1,600万バイトへ：パラメーターでのオプトインが必要で、プロビジョニング済みクラスターは再起動、テーブルのVARCHAR(MAX)列は変わらず、設定後は既定に戻せない

2026年11月6日、AWSはAmazon RedshiftのSUPERデータ型で、個々の文字列を最大1,600万バイトまで保存できるようになったと発表しました。従来の上限は65,535バイトでした。JSON、PARQUET、TEXT、CSVのファイルから読み込むデータと、抽出・ロード・変換（ELT）の処理で生成されるデータが対象で、AWSによれば、Redshiftが使えるすべてのAWSリージョン（AWS GovCloud（米国）リージョンを含む）で提供されます。重要な条件は発表の冒頭の段落にあります。データベースのパラメーターでオプトインする必要があり、オプトインしなければ何も変わりません。

用途は、これまで読み込む前に分割するか切り詰める必要があった半構造化データです。AWSは利用規約や契約書のような長い文書を挙げ、関連するブログ記事は詳細な商品カタログ、アプリケーションの全ログ、顧客とのやり取りの履歴を加えています。こうしたデータがRedshiftに入ると、SQLで問い合わせ、PartiQL言語で調べ、文字列関数で変換できます。AWSは、JSON_PARSE、CONCAT、LISTAGGなどの関数が、最大1,600万バイトの入力文字列を受け取り、同じ長さまでの出力文字列を返せるようになったと述べています。

Redshiftのドキュメントは、オプトインが何をし、制限がどこで止まるかを説明しています。パラメーターはenable_large_strings_opt_inで、値はYes、No、未設定です。未設定ではクラスターの既存の動作が保たれます。Yesにすると、SUPER内の個々の文字列は16,000,000バイトに達でき、メモリ内の文字列関数はその大きさのVARCHAR値を処理でき、CAST式、ビュー、ユーザー定義関数、ストアドプロシージャなどの式の文脈ではVARCHAR(MAX)がVARCHAR(16000000)として解釈されます。保存される列の幅は広がりません。VARCHAR(MAX)でCREATE TABLEしても、作られるのはVARCHAR(65535)の列です。つまり大きなサイズが存在するのはSUPERの値とメモリの中であり、通常のVARCHAR列ではありません。 patch 206以降が必要です。有効化前に作成したビュー、UDF、ストアドプロシージャは再作成するまで65,535バイトの上限が残ります。通常のVARCHAR列は広がらず、従来のSUPERオブジェクト全体の16 MB上限は今回の単一文字列16,000,000バイトとは別です。

オンにする前に重要な運用上の点がいくつかあります。プロビジョニング済みクラスターはパラメーターを反映するために再起動が必要で、Amazon Redshift Serverlessではパラメーターグループの代わりにワークグループの構成パラメーターを使います。パラメーターをYesまたはNoに設定すると、既定値には戻せず、ResetClusterParameterGroupでリセットしても元の値が保たれます。`SELECT is_large_string_enabled();`で現在の状態を確認できます。関連ブログの例は、COPYで大きなJSONドキュメントを読み込む際に`FORMAT JSON 'noshred'`オプションを使い、各ドキュメントを1つのSUPER値のまま保ちます。ブログは3つの強化を並べています。大きな文字列、切り詰めのないメモリ内の文字列操作、大文字小文字を区別しないデータベースでのSUPERの対応で、キャメルケースの属性名のための`enable_case_sensitive_super_attribute`設定もあります。当方はこれらを実行していません。 データ共有の生産側と消費側のウェアハウスはenable_large_strings_opt_inの設定をそろえる必要があります。未設定の既定値に戻せないことは、Noを明示的に選べないという意味ではありません。

発表と文書には1,600万バイト近い文字列の読み込み時間、メモリ使用量、クエリ遅延の数字がなく、価格への影響も説明されていません。料金は別途確認が必要です。関連ブログは以前のディスク退避が性能を損ねたと述べますが、測定は示しません。クライアントツール、ドライバー、エクスポート処理の大きな値への対応は実測しておらず、製品ごとに確認が必要です。一方、既存オブジェクトとデータ共有の制限は関連ブログに明記されています。

当方の見方では、SUPERに大きなJSONドキュメントを置く人にとってハードな上限を外す、有用で範囲の狭い変更で、オプトイン方式が既存の負荷を守っています。同時に、YesかNoを選ぶと未設定の既定には戻せず、テーブル定義は変わりません。チームはまず本番ではないクラスターで、再起動の枠も含めて試し、クライアントツールと下流のクエリが非常に大きな値に対応できるかを確かめてから、本番でパラメーターを設定するか決めるべきです。