O DynamoDB é schemaless?

Sim. O DynamoDB é schemaless. Fora a chave primária, você não define nenhum atributo ou tipo de dado ao criar uma tabela. Cada item pode carregar o próprio conjunto distinto de atributos, e eles podem variar livremente de um item para o outro — então você adapta seu modelo de dados sem rodar migrações de schema.

O que você define de antemão

Só a chave primária: uma chave de partição (obrigatória) e uma chave de ordenação opcional, além dos tipos delas. Todo o resto é arbitrário. Você não declara colunas.

O que varia por item

Dois itens quaisquer da mesma tabela podem ter atributos completamente diferentes. Um item pode guardar email e status; outro pode guardar orderTotal e um mapa address aninhado. O DynamoDB armazena o que você escrever.

Onde o schemaless para

O schemaless tem uma fronteira precisa. A chave primária é validada em toda escrita; nada além dela é. Dois itens sem nenhum atributo em comum entram na mesma tabela sem reclamação:

await client.send(
  new PutItemCommand({
    TableName: 'people',
    Item: {pk: {S: 'USER#1'}, email: {S: 'a@b.c'}, status: {S: 'active'}}
  })
);
await client.send(
  new PutItemCommand({
    TableName: 'people',
    Item: {
      pk: {S: 'ORDER#1'},
      orderTotal: {N: '42.5'},
      address: {M: {city: {S: 'Madrid'}}},
      tags: {SS: ['a', 'b']}
    }
  })
);

As duas dão certo. Agora escreva a mesma chave de partição como número em vez de string:

ValidationException: One or more parameter values were invalid: Type mismatch for key
HTTP 400

E omita o pk por completo:

ValidationException: One of the required keys was not given a value
HTTP 400

Essas duas rejeições são o schema inteiro. O atributo de chave precisa estar presente e precisa bater com o tipo declarado em AttributeDefinitions. Tudo além disso é aceito como foi escrito.

Um erro de digitação também passa. Nada te avisa no momento da escrita que staus deveria ser status.

Por que isso ajuda

Sem migrações — adicione ou remova atributos a qualquer momento.
Entidades misturadas — muitos tipos de entidade podem compartilhar uma tabela (single-table design).
Evolutivo — o modelo muda conforme os requisitos mudam.

Quem impõe qualquer formato do qual você dependa é a sua aplicação, não o banco de dados.

O que o schemaless não relaxa

Schemaless vale só para atributos que não são chave. Todo outro limite do DynamoDB continua valendo:

400 KB por item — nomes e valores de atributo entram no teto.
32 níveis de aninhamento para maps e lists dentro de um valor.
65.535 bytes de comprimento máximo para um único nome de atributo.
25 items no máximo por chamada BatchWriteItem.

Você pode colocar uma string status num item e omiti-la no seguinte, mas não pode guardar um blob de 500 KB em nenhum dos dois. Use a calculadora de tamanho de item para medir um payload antes de escrever, e leia single-table design quando misturar tipos de entidade numa tabela.

No DynoTable: abra Configurações em qualquer tabela e indexe-a. O schema inferido é montado a partir de items amostrados e rotulado com honestidade — mostra o que você escreveu, não o que declarou. Veja Visão geral e indexação da tabela sobre como o índice local amostra e atualiza.

Aprofunde-se

Veja single-table design e o padrão do atributo type para itens misturados. Baixe o DynoTable para inspecionar formatos reais de itens.

Referências

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

Reproduzido em 2026-07-28 contra o DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 no Node v24.18.0. As duas mensagens de ValidationException são saída literal do motor.