Amazon Redshift Lifts the SUPER String Limit From 65,535 to 16 Million Bytes, but Only After an Opt-In Parameter, a Reboot on Provisioned Clusters, With VARCHAR(MAX) Table Columns Unchanged and No Way Back to the Default

On November 6, 2026, AWS announced that Amazon Redshift can now store individual strings of up to 16 million bytes in the SUPER data type, up from 65,535 bytes. It applies to data loaded from JSON, PARQUET, TEXT and CSV files and to data produced by extract, load and transform (ELT) jobs, and AWS says it is available in every AWS Region where Redshift runs, including the AWS GovCloud (US) Regions. The key condition is in the opening paragraph of the announcement: you must opt in through a database parameter. Without the opt-in, nothing changes.

The use case is semi-structured data that used to be split or truncated before loading. AWS names lengthy documents such as terms and conditions and contracts, and its companion blog post adds detailed product catalogs, full application logs and customer interaction histories. Once such data is in Redshift, it can be queried with SQL, explored with the PartiQL language and transformed with string functions. AWS says functions such as JSON_PARSE, CONCAT and LISTAGG can now take input strings and return output strings of up to 16 million bytes.

The Redshift documentation explains what the opt-in does and where the limit stops. The parameter is enable_large_strings_opt_in, with the values Yes, No or not set, and not set keeps the cluster's existing behavior. When set to Yes, individual strings in SUPER can reach 16,000,000 bytes, in-memory string functions can process VARCHAR values of that size, and VARCHAR(MAX) resolves to VARCHAR(16000000) in expression contexts such as CAST expressions, views, user-defined functions and stored procedures. It does not widen stored columns: CREATE TABLE with VARCHAR(MAX) still creates a VARCHAR(65535) column. So the large size lives in SUPER values and in memory, not in ordinary VARCHAR columns. Patch 206 or later is required. Existing views, UDFs and stored procedures remain capped at 65,535 bytes until recreated; ordinary VARCHAR columns do not widen. The existing 16 MB SUPER-object limit is a different boundary from this 16,000,000-byte single-string limit.

Several operational details matter before anyone turns it on. A provisioned cluster must be rebooted to apply the parameter, while Amazon Redshift Serverless uses a configuration parameter on the workgroup instead of a parameter group. After you set the parameter to Yes or No, you cannot reset it to the default, and a reset through ResetClusterParameterGroup keeps the original value. The command `SELECT is_large_string_enabled();` shows the current state. The companion blog's example loads large JSON documents with COPY using the `FORMAT JSON 'noshred'` option so that each document stays a single SUPER value. The blog frames three enhancements: large strings, in-memory string operations without truncation, and SUPER in case-insensitive databases, with an `enable_case_sensitive_super_attribute` setting for camelCase attribute names. We did not run any of this. For data sharing, producer and consumer warehouses must use the same enable_large_strings_opt_in setting. Inability to reset to the unset default does not mean No cannot be explicitly selected.

The announcement and docs give no load-time, memory-use or query-latency figures for strings near 16 million bytes. The reviewed sources do not state the pricing effect, which needs a separate check. The blog says disk spills used to hurt performance but shows no measurement. Specific client tools, drivers and exports have not been tested with very large values and need tool-by-tool checks; the existing-object and data-sharing restrictions above are explicitly documented by the blog.

Our reading: this is a useful, narrow change that removes a hard limit for people who keep big JSON documents in SUPER, and the opt-in design protects existing workloads. It is also a setting you cannot return to the unset default once you choose Yes or No, and it does not change table definitions. A team should try it first on a non-production cluster, reboot window included, check that its client tools and downstream queries cope with very large values, and only then decide whether to set the parameter on production.