Redshift agora armazena strings de até 16 milhões de bytes dentro do tipo SUPER

O que mudou

Desde 6 de novembro de 2026, o Amazon Redshift aceita strings individuais de até 16 milhões de bytes dentro de colunas do tipo SUPER, usado para dados estruturados e semi-estruturados. Antes, cada string guardada num campo SUPER tinha teto de 65.535 bytes, pouco mais de 64 KB. É um salto de ordem de grandeza, não um ajuste incremental.

O novo limite vale em dois cenários: na ingestão de dados a partir de arquivos JSON, PARQUET, TEXT e CSV, e durante transformações dentro de pipelines ELT (extract, load, transform).

Como habilitar

O recurso não vem ligado por padrão: é preciso opt-in através de um parâmetro de banco de dados. A AWS não detalhou o nome exato do parâmetro no anúncio, só indica que, sem ativá-lo, o comportamento antigo (limite de 65.535 bytes) continua valendo. Quem administra o cluster precisa checar a documentação do Redshift antes de assumir que o aumento já está em vigor em produção.

Vale testar em ambiente de homologação antes de ativar: qualquer pipeline downstream que dependa do limite antigo (por exemplo, truncando string em 64 KB manualmente antes de um INSERT) passa a receber dados maiores assim que o parâmetro é ligado, e isso pode exigir ajuste em código de consumo.

Funções que ganham o limite maior

Três funções são citadas explicitamente no anúncio como beneficiadas: JSON_PARSE, CONCAT e LISTAGG. Todas passam a aceitar entrada e devolver saída de até 16 milhões de bytes, contra o limite anterior.

Na prática, isso destrava casos como:

• Um LISTAGG que concatena múltiplos registros de log num único campo de texto, sem estourar o limite antes de chegar no fim da agregação.
• Um JSON_PARSE que converte um documento JSON grande (um payload de evento, um contrato) direto para SUPER, sem pré-quebrar o conteúdo em fragmentos menores.
• Um CONCAT que junta descrições longas vindas de fontes diferentes antes de gravar o resultado.

Por que isso importa pra quem desenha o pipeline de ETL

Antes deste aumento, quem trabalhava com documentos longos (contratos, termos de uso, descrições extensas de produto, blobs de log semi-estruturado) precisava de uma etapa extra antes do load: quebrar a string em pedaços menores que 65.535 bytes, geralmente num job de Glue, numa função Lambda ou num script Python rodando fora do Redshift, só para o dado caber na coluna SUPER.

Essa etapa de pré-processamento tinha custo: tempo de desenvolvimento para escrever a lógica de split, processamento extra rodando fora do cluster e, na reconstrução da string original, mais uma etapa de CONCAT ou LISTAGG no outro lado do pipeline. Com o novo limite, esse documento inteiro cabe direto na coluna, sem transformação prévia.

O próprio anúncio cita o exemplo de termos e condições e contratos como o tipo de documento que agora entra direto. Para quem constrói pipeline de dados sobre Redshift, isso significa menos uma etapa de processamento para manter, testar e monitorar, e um pipeline de ingestão mais curto entre a origem do dado e a tabela final.

Uma vez dentro do Redshift, o dado grande fica navegável com PartiQL, a extensão de SQL para dados semi-estruturados, ou pode ser manipulado com as funções de string padrão do Redshift. Isso abre espaço para consultas analíticas diretamente sobre o conteúdo de documentos longos, sem precisar de um serviço externo só para indexar ou buscar texto dentro deles.

Onde já está disponível

O recurso está disponível em todas as regiões AWS onde o Redshift opera, incluindo as regiões AWS GovCloud (US), segundo a AWS Region Table citada no anúncio.

O que ainda não está claro

O anúncio não traz detalhes sobre impacto em memória do cluster, em custo de armazenamento ou em desempenho de consulta ao trabalhar com strings na casa dos megabytes dentro de colunas SUPER. Também não há menção a mudança de preço: o aumento de limite, pelo que a AWS publicou, não vem acompanhado de cobrança adicional específica.

Antes de ativar o parâmetro em produção, vale medir o comportamento do cluster com uma amostra representativa dos documentos grandes que você pretende carregar, principalmente se o workload já estiver no limite de WLM ou de memória por nó. A AWS recomenda consultar a documentação e o blog técnico do Redshift para o passo a passo completo de ativação.

Fonte 1: AWS What's New (https://aws.amazon.com/about-aws/whats-new/2026/11/amazon-redshift-expands-super-to-16-million-bytes/)

Amazon Redshift expands SUPER data type to store strings up to 16 million bytes - AWS

Skip to main content

Amazon Redshift expands SUPER data type to store strings up to 16 million bytes

Posted on: Nov 6, 2026

Amazon Redshift now supports individual strings up to 16 million bytes within SUPER data types . Once you opt in through a database parameter, this enhancement applies when ingesting structured or semi-structured data from JSON, PARQUET, TEXT, and CSV source files, and when transforming data through extract load and transform (ELT) processes. Previously, individual strings within SUPER data types were limited to 65,535 bytes.

Storing large individual strings in the SUPER data type helps avoid complex pre-loading transformations needed to store the source data in Amazon Redshift. You can now directly ingest large individual strings greater than 65,535 bytes without extra processing (for example, lengthy documents like terms and conditions and contracts), making them queryable using SQL. Once the data is in Amazon Redshift, you can use the flexibility of PartiQL language to explore and navigate through the data or use string functions to transform the data. Functions such as JSON_PARSE , CONCAT , and LISTAGG can now take input strings and return output strings up to 16 million bytes in length.

This enhancement is available in all AWS Regions, including the AWS GovCloud (US) Regions, where Amazon Redshift is available. See the AWS Region Table for more details. To learn more, please visit our documentation or blog .

Fonte: AWS What's New