O DynamoDB consegue armazenar blobs?

Sim, dentro de limites. O DynamoDB armazena objetos binários grandes (BLOBs) em atributos Binary (B), codificados em base64 no tráfego, desde que o item inteiro fique abaixo de 400 KB. Para qualquer coisa maior — vídeo, áudio, imagens de alta resolução — a AWS recomenda armazenar o blob no Amazon S3 e manter apenas uma referência e os metadados no DynamoDB.

Armazenando um blob diretamente

Coloque os bytes em um atributo Binary. As aplicações codificam valores binários em base64 antes de enviar; o DynamoDB conta o comprimento em bytes brutos para o limite de 400 KB do item. Blobs pequenos (assinaturas, payloads compactos) cabem confortavelmente.

Quantos bytes cabem de verdade

400 KB é o item, não o blob. Buscar o limite por busca binária dá um teto exato: um item que contém apenas uma chave de partição de um caractere e um atributo Binary aceita 409.594 bytes de blob. Um byte a mais e a escrita falha:

ValidationException: Item size has exceeded the maximum allowed size

Seis atributos de metadados realistas ao lado dele (tipo de conteúdo, dimensões, quem enviou, timestamp) custam 94 bytes e derrubam o teto para 409.500.

A codificação base64 é um detalhe de tráfego e nada mais. Aquele put de 409.594 bytes envia 546.128 bytes de base64 no corpo da requisição e o DynamoDB o aceita, então a ideia amplamente repetida de que o base64 come um terço do seu orçamento está errada. O que ele custa de fato é throughput: um blob de tamanho máximo são 400 unidades de escrita por put e 100 unidades de leitura por leitura com consistência forte, contra 1 e 0,5 de um item pequeno.

O padrão de objeto grande

Quando um blob passa de 400 KB:

Armazene o objeto no Amazon S3.
Mantenha a chave do S3 mais os metadados (nome, tamanho, dono, timestamps) no DynamoDB.

Isso combina as buscas indexadas rápidas do DynamoDB com o armazenamento de objetos barato e ilimitado do S3. Para dados apenas modestamente acima do limite, a AWS também sugere comprimir atributos grandes (saída GZIP ou LZO armazenada em um atributo Binary) ou dividi-los entre múltiplos itens.

A compressão salva texto, não mídia

Esse conselho de compressão funciona para exatamente um tipo de blob. gzip -9 sobre um lockfile YAML de 614.499 bytes devolve 164.302 bytes, um corte de 73% que o leva do impossível ao confortável. O mesmo comando sobre um PNG de 794.311 bytes devolve 785.175 bytes, uma economia de 1,2%, porque o formato já se comprimiu sozinho. Ou seja, a compressão te compra espaço para logs, payloads JSON e texto, e não te compra nada para os arquivos de mídia que são o motivo habitual de bater no limite.

Uma ressalva

Não existem transações entre serviços do DynamoDB e do S3, então a sua aplicação precisa lidar com falhas parciais e objetos órfãos por conta própria.

Aprofunde-se

Confira tamanhos com a calculadora de tamanho de item e leia o guia sobre o limite de tamanho de item. Baixe o DynoTable para visualizar dados binários.

Referências

Verificado pela última vez em 2026-07-13 contra a documentação oficial da AWS vinculada acima.

Medido em 2026-07-28 contra o DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 — os dois tetos em bytes foram encontrados por busca binária, e não derivados, e os números do gzip vêm de rodar gzip -9 nos dois arquivos descritos. O motor de produção da AWS pode redigir suas rejeições de forma diferente.