The practical takeaway first

Amazon’s November 6, 2026 announcement is useful, but it is easy to misread. When you opt in, individual strings inside SUPER can grow from 65,535 bytes to 16,000,000 bytes. That is a byte limit, not a character count, and it does not mean every near-limit JSON document or enclosing SUPER object will fit automatically. If you are migrating pipelines or revisiting assumptions about semi-structured data, test the full path before you turn the feature on in production.

The safest way to approach this change is to treat it as three separate gates: the decoded UTF-8 string itself, the enclosing SUPER object and ingestion path, and the downstream schema that receives the data. A value that passes one gate can still fail at the next.

A data string passes through a document container and then into a database column.
A data string passes through a document container and then into a database column.

1) Test the individual UTF-8 value, not just the human-readable text

The new limit applies to bytes. That matters because characters and bytes are not the same thing in UTF-8. A plain ASCII string is one byte per character, but a multibyte character can consume more. For example, a precomposed U+00E9 character such as “é” is two UTF-8 bytes. If you only count characters, you can understate the true size of the payload.

For a migration test, start with a small control value, then a 65,535-byte decoded ASCII string, then a 65,536-byte decoded ASCII string. Add a multibyte sample as well. Record the raw UTF-8 length of each decoded value separately from the serialized JSON length, because those two numbers can differ.

  • Control sample: a short string that should obviously pass.
  • Boundary sample 1: 65,535 decoded ASCII bytes.
  • Boundary sample 2: 65,536 decoded ASCII bytes.
  • Multibyte sample: a string that includes precomposed U+00E9 and similar characters.
  • For each sample, log the decoded UTF-8 byte length and the serialized JSON size.

2) Check the enclosing SUPER object and input path

A value can fit inside the expanded string limit and still fail because the full JSON object, ingestion route, or document structure does not. That is why the field size alone is not enough. The object that carries the value may have its own practical ceiling, and the way you load data into Redshift can introduce separate restrictions.

In other words, do not test only a standalone string and assume the pipeline is safe. Wrap that same value in the real document shape you use in production. Then run the same checks through the same ingestion path, whether you are loading from files, staging systems, or application output. AWS documentation for SUPER limitations and behavior changes is the place to confirm the current operational boundaries for your environment.

For example, a product feed might carry both a long description and a second field containing image data. The description can pass the string check while the full object still exceeds the 16 MB SUPER object limit. If you load JSON or CSV with COPY, check the separate row scanner limit as well. A raw JSON byte count helps you plan the test; it does not measure Redshift’s internal representation.

3) Confirm the downstream storage schema

The last trap is assuming every VARCHAR(MAX) name now means the same thing everywhere. In Redshift, the in-memory VARCHAR(MAX) behavior resolves to 16,000,000 with the opt-in setting, but CREATE TABLE VARCHAR(MAX) remains 65,535 bytes. Those are not interchangeable. If your design depends on a table definition, an intermediate transform, or a materialized output column, verify the exact schema behavior rather than assuming the larger SUPER string allowance will propagate automatically.

That distinction matters in migration plans. You may successfully read or process a larger value in a SUPER context, yet still lose it when you persist it to a table column that uses the older CREATE TABLE limit. The practical test is simple: move the same sample through the full chain and verify what survives at each step.

How to test before rollout

AWS documents a reboot for provisioned clusters after changing the setting. Check the patch and configuration on your staging warehouse first, and plan the production change for a suitable maintenance window. AWS also says that after enabling the parameter, you cannot reset it to its default through ResetClusterParameterGroup.

Record the load outcome, decoded byte count after retrieval, and the result of writing to the actual destination column. For a more complete test, include a synthetic sample near your largest expected production value. If the load succeeds but the downstream write fails, inspect the target column before changing the input pipeline.

If you do this carefully, the new SUPER string support can be an upgrade rather than a surprise. The key is to treat the announcement as a larger allowance for one layer of the pipeline, not as proof that every layer below it has changed too.

Sources

AWS announcement: Amazon Redshift expands SUPER to 16 million bytes

Opt in guidance for large strings in SUPER

Redshift SUPER limitations

Behavior changes in Amazon Redshift