[アップデート] Amazon Redshift の SUPER データ型で最大 16,000,000 バイトの文字列を格納できるようになったので試してみた

クラウド事業統括本部の石川です。Amazon Redshift の SUPER データ型で、個々の文字列を最大 16,000,000 バイトまで格納できるようになりましたので、Amazon Redshift Serverless で AWS ブログのサンプルデータを使って試してみました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/11/amazon-redshift-expands-super-to-16-million-bytes/

Amazon Redshift の SUPER データ型で、個々の文字列を最大 16,000,000 バイトまで格納できるようになりました。これまでの上限は 65,535 バイトでした。

データベースパラメータでオプトインすると、JSON、PARQUET、TEXT、CSV のソースファイルからの取り込みと、ELT 処理での変換にこの上限が適用されます。契約書や長いログのように 65,535 バイトを超える文字列を含む JSON を、分割や切り詰めをせずにロードし、SQL で参照できるようになります。JSON_PARSE、CONCAT、LISTAGG も、最大 16,000,000 バイトの文字列を入力として受け取り、出力できるようになりました。

AWS GovCloud (US) リージョンを含む、Amazon Redshift が利用可能なすべての AWS リージョンで利用できます。

本記事では、検証専用の Amazon Redshift Serverless ワークグループでパラメータを有効にし、AWS ブログの手順（JSON のロード、文字列関数、LISTAGG）と、日本語の文字列での上限を確認しました。

https://aws.amazon.com/blogs/big-data/store-and-process-large-strings-in-amazon-redshift-super-columns/

SUPER データ型の大きな文字列サポートとは

SUPER データ型は、JSON などの半構造化データ（semi-structured data）を、スキーマを定義せずに格納する Amazon Redshift のデータ型です。配列やネストした構造を 1 つの値として保持でき、配列や構造の中の要素は PartiQL の構文で参照します。ドキュメントでは、個々の SUPER オブジェクトは最大 16 MB のデータをサポートされました。今回引き上げられたのは、SUPER の中に含まれる個々の文字列の上限です。

https://docs.aws.amazon.com/redshift/latest/dg/r_SUPER_type.html

大きな文字列のサポートは、パラメータ enable_large_strings_opt_in で有効化が必要です。値は Yes、No、未設定（デフォルト）の 3 つで、未設定の場合は既存の動作が維持されます。値ごとの動作は以下のとおりです。

AWS ブログでは、Patch 206 以降（current メンテナンストラック）の Amazon Redshift が前提条件として挙げられています。プロビジョニング済みクラスターでは、パラメータグループで enable_large_strings_opt_in を Yes に設定してクラスターにアタッチし、クラスターを再起動します。Amazon Redshift Serverless はパラメータグループを使わないため、ワークグループの設定でパラメータを指定します。現在の状態は SELECT is_large_string_enabled(); で確認できます。

ドキュメントと AWS ブログには、以下の注意点が記載されています。

• 一度 Yes または No に設定すると、デフォルト（未設定）には戻せません。ResetClusterParameterGroup でリセットしても、設定済みの値が維持されます
• パラメータを有効にすると、CAST やビューなどの式の中では VARCHAR(MAX) が VARCHAR(16000000) として扱われますが、テーブルの列は対象外です。CREATE TABLE で VARCHAR(MAX) を指定しても VARCHAR(65535) の列が作成されるため、SUPER 列から取り出した 65,535 バイトを超える文字列や、LISTAGG などの結果をテーブルに保存する場合は SUPER 列に格納します

注意が必要な点は、このパラメータが SUPER 列だけでなく、文字列関数やキャストで扱う VARCHAR の長さの上限も変えます。ただし、上限が広がるのは式の中で扱う値だけで、テーブルの VARCHAR 列は対象外です。

• パラメータを有効にする前に作成したビュー、UDF、ストアドプロシージャは、再作成するまで 65,535 バイトが上限のままです
• VARCHAR(MAX) を使うビューに他のビューなどが依存している場合、CREATE OR REPLACE VIEW は「cannot change data type of view column」エラーで失敗します。依存するオブジェクトを削除し、ビューを削除して再作成したあと、依存するオブジェクトを再作成します
• データ共有を利用している場合は、プロデューサーとコンシューマーのデータウェアハウスで設定を揃えます
• SUPER 列に 65,535 バイトを超える文字列を含むスナップショットを、このパラメータが No のクラスターに復元すると、長い文字列の取り込みに失敗する場合があります

やってみた

前提条件

• リージョン: 東京リージョン
• Amazon Redshift Serverless: Patch 206（current トラック、ワークグループバージョン 1.0.535482）、ベース容量 4 RPU
• AWS CLI 2.39.5
• サンプルデータ: AWS ブログで配布されている orders.json

enable_large_strings_opt_in は一度設定すると未設定に戻せないため、既存のワークグループは使わず、検証専用の名前空間とワークグループを作成しました。検証の流れは以下のとおりです。

検証環境を作成する

東京リージョンに下記の条件で RedshiftServerless を構築しました。

作成したワークグループのパッチバージョンとパラメータは以下のとおりです。

% aws redshift-serverless get-workgroup \
  --workgroup-name super16m-wg \
  --query "workgroup.{status:status,patchVersion:patchVersion,trackName:trackName,workgroupVersion:workgroupVersion,baseCapacity:baseCapacity,configParameters:configParameters[?parameterKey==\`enable_large_strings_opt_in\`]}"
{
    "status": "AVAILABLE",
    "patchVersion": "206",
    "trackName": "current",
    "workgroupVersion": "1.0.535482",
    "baseCapacity": 4,
    "configParameters": [
        {
            "parameterKey": "enable_large_strings_opt_in",
            "parameterValue": ""
        }
    ]
}

パッチバージョンは 206 で、enable_large_strings_opt_in の値は空文字（未設定）でした。

マネジメントコンソールのワークグループ画面でも、Patch 206 と Track Current を確認できます。

なお、コンソールのワークグループ画面では、アクションメニュー（ワークグループの削除、トラックの編集、使用制限の管理など）と 6 つのタブ（クエリとデータベースモニタリング、データアクセス、制限、Performance、タグ、Autonomics）のいずれにも、enable_large_strings_opt_in を表示・設定する項目は見当たりませんでした。そのため、パラメータは AWS CLI で変更・確認しています。

大きな文字列のサポートを有効にする

Amazon Redshift Serverless では、update-workgroup の --config-parameters でパラメータ（enable_large_strings_opt_in）を変更します。

% aws redshift-serverless update-workgroup \
  --workgroup-name super16m-wg \
  --config-parameters parameterKey=enable_large_strings_opt_in,parameterValue=Yes \
  --query "workgroup.{status:status,configParameters:configParameters[?parameterKey==\`enable_large_strings_opt_in\`]}"
{
    "status": "MODIFYING",
    "configParameters": [
        {
            "parameterKey": "enable_large_strings_opt_in",
            "parameterValue": "Yes"
        }
    ]
}

ステータスは MODIFYING になり、10 秒間隔で確認したところ、約 1 分 45 秒後に AVAILABLE に戻りました。

% aws redshift-serverless get-workgroup \
  --workgroup-name super16m-wg \
  --query "workgroup.{status:status,configParameters:configParameters[?parameterKey==\`enable_large_strings_opt_in\`]}"
{
    "status": "AVAILABLE",
    "configParameters": [
        {
            "parameterKey": "enable_large_strings_opt_in",
            "parameterValue": "Yes"
        }
    ]
}

変更前後で configParameters 全体を比較すると、値が変わったのは enable_large_strings_opt_in だけで、他のパラメータ（auto_mv、datestyle、require_ssl、max_query_execution_time など）は変更前の値のままでした。

SQL の実行方法

まず、大きな文字列のサポートの状態を確認します。

SELECT is_large_string_enabled();

% aws redshift-data get-statement-result --id aebe60e7-2a69-4e80-bb08-139b7d5e7568
{
    "Records": [
        [
            {
                "booleanValue": true
            }
        ]
    ],
    "ColumnMetadata": [
        {
            "isCaseSensitive": false,
            "isCurrency": false,
            "isSigned": false,
            "label": "is_large_string_enabled",
            "name": "is_large_string_enabled",
            "nullable": 1,
            "precision": 1,
            "scale": 0,
            "schemaName": "",
            "tableName": "",
            "typeName": "bool",
            "length": 0
        }
    ],
    "TotalNumRows": 1
}

is_large_string_enabled() は true を返しました。以降は、実行した SQL と、get-statement-result の結果を表にまとめたものを掲載します。エラーになった場合は、describe-statement の Error の内容を掲載します。

大きな文字列を含む JSON をロードする

AWS ブログで配布されているサンプルの orders.json を使います。

https://d2908q01vomqb2.cloudfront.net/artifacts/DBSBlogs/BDB-5835/orders.json

ファイルサイズは 3,203,661 バイトで、5 件の注文データ（JSON オブジェクト）が含まれています。各注文の detailedDescription は 242,400 バイト、transactionLogs は 397,600 バイトの文字列（いずれも ASCII 文字のみ）で、どちらも 65,535 バイトを超えています。このファイルを S3 にアップロードします。

% aws s3 cp orders.json s3://super16m-123456789012-ap-northeast-1/testdata/orders.json --no-progress
upload: ./orders.json to s3://super16m-123456789012-ap-northeast-1/testdata/orders.json

AWS ブログの例と同じく、SUPER 列を 1 つ持つテーブルを作成し、FORMAT JSON 'noshred' で COPY します。

CREATE TABLE orders (data SUPER);

COPY orders
FROM 's3://super16m-123456789012-ap-northeast-1/testdata/orders.json'
IAM_ROLE 'arn:aws:iam::123456789012:role/super16m-copy-role'
FORMAT JSON 'noshred';

COPY はエラーにならずに完了しました。SYS_LOAD_HISTORY でロードの結果を確認します。

SELECT query_id, status, TRIM(table_name) AS table_name, file_format,
       loaded_rows, loaded_bytes, source_file_count, error_count
FROM sys_load_history
WHERE table_name = 'orders'
ORDER BY start_time DESC LIMIT 1;

5 行がロードされました。ロードしたデータの中身を確認します。JSON の属性名が camelCase のため、enable_case_sensitive_super_attribute を true に設定してから参照します。

SET enable_case_sensitive_super_attribute TO true;

SELECT data.orderId::VARCHAR                     AS order_id,
       data.customerId::VARCHAR                  AS customer_id,
       data.status::VARCHAR                      AS status,
       data.shippingAddress.state::VARCHAR       AS shipping_state,
       LENGTH(data.detailedDescription::VARCHAR) AS description_length,
       LENGTH(data.transactionLogs::VARCHAR)     AS logs_length
FROM orders
ORDER BY 1;

65,535 バイトを超える 242,400 文字と 397,600 文字の文字列が、切り詰められずに格納されていました。

文字列関数は VARCHAR にキャストしてから使う

AWS ブログでは、SUPER 列の値に文字列関数を直接適用するとエラーになる例と、VARCHAR にキャストしてから適用する例が紹介されています。まず、lower を SUPER の値に直接適用してみます。

SET enable_case_sensitive_super_attribute TO true;

SELECT lower(data.customerId) AS customer_id FROM orders;

ERROR: function lower(super) does not exist
  Hint: No function matches the given name and argument types. You may need to add explicit type casts.

lower 関数に SUPER 型の引数を受け付ける定義がないため、エラーになりました。customerId は 10 バイトの文字列なので、このエラーは文字列の長さとは関係なく発生しています。VARCHAR にキャストしてから適用します。

SET enable_case_sensitive_super_attribute TO true;

SELECT lower(data.customerId::VARCHAR) AS customer_id FROM orders ORDER BY 1;

キャストすると、小文字に変換された値が返りました。65,535 バイトを超える detailedDescription と transactionLogs にも、キャストしてから文字列関数を適用してみます。

SET enable_case_sensitive_super_attribute TO true;

SELECT data.orderId::VARCHAR AS order_id,
       LENGTH(lower(data.detailedDescription::VARCHAR)) AS lower_desc_length,
       LENGTH(upper(data.transactionLogs::VARCHAR))     AS upper_logs_length,
       RIGHT(upper(data.transactionLogs::VARCHAR), 30)  AS upper_logs_tail
FROM orders
ORDER BY 1;

lower と upper の結果の長さは元の文字列と同じ 242,400 文字と 397,600 文字で、末尾の 30 文字も大文字に変換されて返りました。65,535 バイトを超える文字列も、切り詰められずに処理されています。

LISTAGG で連結した文字列を SUPER 列に格納する

AWS ブログと同じクエリで、5 件の detailedDescription を LISTAGG で連結し、結果の文字数を確認します。

SET enable_case_sensitive_super_attribute TO true;

SELECT LEN(LISTAGG(data.detailedDescription::VARCHAR, ', ')
           WITHIN GROUP (ORDER BY data.orderId::VARCHAR)) AS description_length
FROM orders
WHERE data.status::VARCHAR = 'processing';

AWS ブログに記載されているとおり、1,212,008 文字になりました（242,400 文字 × 5 件と、区切り文字 , の 2 文字 × 4 か所）。

AWS ブログでは、LISTAGG の結果が VARCHAR 列の上限である 65,535 バイトを超える場合は、SUPER 列に格納できると説明されています。SUPER 列と VARCHAR(MAX) 列のテーブルを作成し、LISTAGG の結果をそれぞれに格納してみます。

CREATE TABLE order_desc_super (descriptions SUPER);
CREATE TABLE order_desc_varchar (descriptions VARCHAR(MAX));

SET enable_case_sensitive_super_attribute TO true;

-- SUPER 列に格納する
INSERT INTO order_desc_super
SELECT LISTAGG(data.detailedDescription::VARCHAR, ', ') WITHIN GROUP (ORDER BY data.orderId::VARCHAR)
FROM orders WHERE data.status::VARCHAR = 'processing';

-- VARCHAR(MAX) 列に格納する
INSERT INTO order_desc_varchar
SELECT LISTAGG(data.detailedDescription::VARCHAR, ', ') WITHIN GROUP (ORDER BY data.orderId::VARCHAR)
FROM orders WHERE data.status::VARCHAR = 'processing';

SUPER 列への INSERT は成功し、VARCHAR(MAX) 列への INSERT は以下のエラーになりました。

ERROR: Value too long for character type
  Detail:
  -----------------------------------------------
  error:  Value too long for character type
  code:      8001
  context:   Value too long for type character varying(65535)
...

SUPER 列に格納した値と、VARCHAR(MAX) 列の定義を確認します。

SELECT JSON_TYPEOF(descriptions) AS type,
       LEN(descriptions::VARCHAR) AS chars,
       OCTET_LENGTH(descriptions::VARCHAR) AS bytes
FROM order_desc_super;

SELECT table_name, column_name, data_type, character_maximum_length
FROM svv_columns
WHERE table_schema = 'public' AND table_name = 'order_desc_varchar';

SUPER 列には、1,212,008 バイトの文字列として格納されていました。パラメータを有効にした後に VARCHAR(MAX) で作成した列は character varying(65535) で、65,535 バイトを超える値は格納できませんでした。

日本語の文字列で確認する

上限が文字数とバイト数のどちらで判定されるかを、UTF-8 で 3 バイトの「あ」で確認します。16,000,000 ÷ 3 = 5,333,333 余り 1 なので、「あ」5,333,333 文字に ASCII の a を 1 文字加えると 16,000,000 バイトになります。

確認用のテーブルを作成します。

CREATE TABLE t_super (id INT, label VARCHAR(50), doc SUPER);

格納する文字列の文字数とバイト数を確認します。

SELECT LEN(REPEAT('あ', 5333333) || 'a') AS chars_a,
       OCTET_LENGTH(REPEAT('あ', 5333333) || 'a') AS bytes_a,
       LEN(REPEAT('あ', 5333334)) AS chars_b,
       OCTET_LENGTH(REPEAT('あ', 5333334)) AS bytes_b;

どちらも 5,333,334 文字で、バイト数だけが異なる文字列です。それぞれ JSON_PARSE で格納してみます。

INSERT INTO t_super VALUES (20, 'ja-16000000', JSON_PARSE('{"body":"' || REPEAT('あ', 5333333) || 'a' || '"}'));

INSERT INTO t_super VALUES (21, 'ja-16000002', JSON_PARSE('{"body":"' || REPEAT('あ', 5333334) || '"}'));

16,000,000 バイトの id=20 は成功し、16,000,002 バイトの id=21 は以下のエラーになりました。

ERROR: Invalid input
  Detail:
  -----------------------------------------------
  error:  Invalid input
  code:      8001
  context:   JSON_PARSE() error: String value exceeds the max size of 16000000 bytes: (16000000 bytes skipped)            "}
...

格納された値を確認します。

SELECT id, label, LEN(doc.body::VARCHAR) AS chars, OCTET_LENGTH(doc.body::VARCHAR) AS bytes,
       SUBSTRING(doc.body::VARCHAR, 1, 5) AS head5
FROM t_super WHERE id >= 20 ORDER BY id;

上限はバイト数で判定されています。日本語（3 バイト文字）だけの文字列であれば、約 533 万文字が上限です。

Query Editor v2 で確認する

マネジメントコンソールの Query Editor v2（フェデレーティッドユーザーで接続）でも、is_large_string_enabled() と LISTAGG の結果を確認しました。

SET enable_case_sensitive_super_attribute TO true;

SELECT is_large_string_enabled() AS large_string_enabled,
COUNT(*) AS orders,
LEN(LISTAGG(data.detailedDescription::VARCHAR, ', ')
WITHIN GROUP (ORDER BY data.orderId::VARCHAR)) AS description_length
FROM orders
WHERE data.status::VARCHAR = 'processing';

large_string_enabled は true、orders は 5、description_length は Data API と同じ 1,212,008 でした。

考察

検証で確認した内容をまとめると、以下のとおりです。

この結果から、以下の点に注意が必要だと考えます。

• Amazon Redshift Serverless では、パラメータの設定と確認は CLI などで行います。 今回確認したコンソールのワークグループ画面には、enable_large_strings_opt_in を表示・設定する項目がありませんでした。設定後の値は、get-workgroup の configParameters か、SELECT is_large_string_enabled(); で確認できます
• SUPER の値に文字列関数を適用するときは、::VARCHAR にキャストします。 キャストしない場合のエラーは関数の引数の型によるもので、短い文字列でも発生しました。キャストすると、65,535 バイトを超える文字列でも結果の長さは元の文字列と同じでした
• 65,535 バイトを超える値をテーブルに保存する場合は、SUPER 列を使います。 パラメータを有効にした後でも、CREATE TABLE で VARCHAR(MAX) を指定した列は character varying(65535) で、LISTAGG の結果（1,212,008 バイト）は格納できませんでした
• 上限は文字数ではなくバイト数です。 UTF-8 で 3 バイトの日本語だけの文字列であれば、約 533 万文字が上限になります。日本語を含むデータの長さを見積もる場合は、文字数ではなく OCTET_LENGTH でバイト数を確認する必要があります
• パラメータは未設定に戻せないため、既存環境で試す前に検証専用の環境で確認することをおすすめします。 今回の Amazon Redshift Serverless では、検証環境の作成が約 1 分 50 秒、パラメータの変更が約 1 分 45 秒で完了しました

今回の検証では、プロビジョニング済みクラスター（パラメータグループとクラスターの再起動）、パラメータを有効にする前の挙動、No に設定した場合の挙動、既存のビュー・UDF・ストアドプロシージャの再作成、データ共有、スナップショットの復元、PARQUET・TEXT・CSV からの COPY は確認していません。

最後に

Amazon Redshift の SUPER データ型で、個々の文字列を最大 16,000,000 バイトまで格納できるようになりました。Amazon Redshift Serverless で enable_large_strings_opt_in を Yes に設定すると、AWS ブログのサンプル orders.json（242,400 バイトと 397,600 バイトの文字列を含む JSON）を COPY でそのまま SUPER 列にロードでき、VARCHAR にキャストした文字列関数や LISTAGG でも、65,535 バイトを超える文字列を切り詰めずに扱えることを確認しました。

一方で、テーブルの VARCHAR(MAX) 列は 65,535 バイトのままで、上限はバイト数で判定されます。また、一度設定するとデフォルトに戻せないことや、既存のビュー・UDF・ストアドプロシージャを再作成する必要があることなど、有効化の前に確認すべき点があります。65,535 バイトの上限に合わせて JSON の分割や切り詰めを行っている場合は、検証専用の環境でパラメータを有効にして既存のロード処理やオブジェクトへの影響を確認したうえで、導入を検討してみてはいかがでしょうか。