Throughput On-Demand do DynamoDB: Medido

Quanto throughput uma nova tabela On-Demand do DynamoDB recebe?

Uma tabela On-demand capacity recém-criada atende cerca de 4.130 gravações por segundo — a AWS documenta 4.000 — e pelo menos 12.700 leituras eventualmente consistentes por segundo. Medimos os dois números em 2026-08-27 contra uma tabela criada minutos antes: as gravações ficaram travadas em 4.130 ±2/s em toda carga oferecida acima da baseline, e as leituras nunca sofreram throttling antes de nosso próprio gerador de carga ficar sem fôlego.

Esses dois números, e tudo mais nesta página, vêm de contar requisições reais contra o serviço ao vivo — não de repetir a documentação. O método, os dados brutos e as três tentativas fracassadas estão escritos na história do benchmark; esta página é a referência onde os números vivem.

O teto de gravação em uma tabela nova

A carga oferecida subiu em janelas de 30 segundos contra uma tabela que nunca tinha visto tráfego. Cada requisição carregava um item de ~1 KB com uma chave uniformemente aleatória — nenhuma Hot partition envolvida:

A baseline documentada de 4.000 gravações/s se confirma, com cerca de 3% de folga acima dela. O teto é notavelmente plano: 4.132, 4.131, 4.134 gravações por segundo alcançadas em 5.000, 6.000 e 8.000 oferecidas. A latência não piora quando você cruza o teto — a latência p50 de gravação ficou em 4–5 ms in-region em todas as janelas. O serviço não desacelera; ele rejeita.

O que o throttling realmente retorna

A primeira rejeição chegou entre 0,9 e 3,8 segundos após o início de cada janela acima da baseline (quanto maior a taxa oferecida, mais cedo ela veio). Ao pé da letra:

ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html

Duas coisas para planejar. É um HTTP 400, não um 5xx — uma política de retentativa ou alarme que só observa 5xx vai deixar passar o throttling on-demand por completo (os SDKs fazem retry disso por padrão; veja Exponential backoff). E a dica de chave quente é uma sugestão padrão, não um diagnóstico — nossas chaves eram uniformemente aleatórias, então em escala pequena o primeiro suspeito para essa mensagem é o teto no nível da tabela, não o seu esquema de chave. As quatro causas distintas de throttling têm seu próprio guia.

O teto de leitura

As leituras rodaram contra uma segunda tabela nova, semeada com 1.000 itens, como GetItems Eventually consistent read (~1 KB, 0,5 unidade de leitura cada):

Zero throttling em toda taxa. A baseline documentada de 12.000 leituras/s se confirma, e não conseguimos encontrar sua borda real: em 16.000/s oferecidos, cinco dos nossos oito runners saturaram do lado do cliente, então 12.762/s é onde nossa frota parou — não onde o DynamoDB parou. As leituras responderam em 2–4 ms p50 in-region.

Como o teto cresce sob carga sustentada

A AWS documenta que a capacidade on-demand cresce para acomodar até o dobro do pico anterior, e que exceder o dobro do pico anterior dentro de 30 minutos pode causar throttling. Mantivemos 8.000 gravações/s de carga oferecida contra uma tabela por 34 minutos contínuos (quatro ondas de 8 minutos com menos de um minuto de pausa entre elas) e observamos o teto se mover, minuto a minuto:

Lendo a linha do tempo:

• O primeiro teto é pegajoso. Durante todos os primeiros 8 minutos a tabela se manteve em sua baseline de ~4.000/s — a demanda sustentada acima do teto não o moveu dentro dessa janela.
• O crescimento chega em passos de ~1.000/s, não em uma rampa. O teto subiu para ~5.000/s por volta do minuto 9, ~6.000/s por volta do minuto 26, e ~7.000/s um minuto depois, e então se manteve em 7.000/s até o fim. Cada passo acontece abruptamente entre um minuto e o próximo. Dois dos três passos aconteceram perto das fronteiras entre nossas ondas, então as pausas de menos de um minuto podem interagir com o mecanismo de crescimento — relatamos o tempo como observado.
• Meia hora de demanda sustentada não dobrou o teto. Depois de 34 minutos com 8.000/s oferecidos, a tabela atendeu 7.000/s — 1,75× seu teto inicial, ainda abaixo tanto da taxa oferecida quanto de uma duplicação limpa. As requisições com throttling caíram de onda para onda (1,9 milhão → 0,5 milhão) à medida que a capacidade crescia.

Se o tráfego do dia do lançamento vai exceder ~4.000 gravações/s em uma tabela nova, pré-aqueça-a: dirija carga sintética antes do evento, ou defina explicitamente o throughput on-demand máximo da tabela e deixe a AWS provisionar para ele. O guia On-Demand vs Provisionada cobre quando cada modo vence, e o auto scaling é a contrapartida no modo provisionado do que você acabou de ver acontecer automaticamente aqui.

Dois números que nos surpreenderam

• O tempo de criação até ACTIVE varia 3×. Uma tabela on-demand nova chegou a ACTIVE em 7,4 segundos em uma execução e em 22 segundos em outras duas, mesma região, mesmo esquema. Reserve orçamento de tempo para o caso lento em qualquer design de tabela por tenant ou tabela por teste.
• O benchmark inteiro custou $0,97. 672.116 gravações faturadas e 1,08 milhão de leituras. A execução de crescimento sustentado de 34 minutos custou mais $12,67. Medir o serviço você mesmo é mais barato do que uma única decisão de capacidade errada — e você pode precificar uma carga de trabalho como essa com antecedência com a calculadora de preços do DynamoDB.

Escopo e método, com honestidade

Tudo acima é uma tabela por fase, um dia, uma região (us-east-1), itens de ~1 KB, chaves uniformemente aleatórias. Os limites por partição (3.000 unidades de leitura / 1.000 unidades de gravação por segundo) ficam abaixo do comportamento no nível da tabela medido aqui e têm seus próprios modos de falha. As cotas no nível da conta e os limites rígidos do serviço estão na referência de limites do DynamoDB, medidos da mesma forma. E se você trabalha com o DynamoDB todo dia, o DynoTable é nosso cliente desktop para ele — construído pela mesma equipe, com o mesmo hábito de checar as afirmações contra o serviço ao vivo antes de repeti-las.