Quão rápido é o DynamoDB?
Rápido. O DynamoDB entrega latência consistente de milissegundos de um dígito para leitura e escrita em qualquer escala. Acrescentar o DynamoDB Accelerator (DAX), um cache em memória, reduz as leituras com consistência eventual a microssegundos. O desempenho se mantém constante conforme as tabelas crescem porque as leituras miram diretamente uma chave de partição em vez de escanear, então a latência não se degrada com o volume de dados.
Por que ele continua rápido em escala
Um GetItem ou Query faz o hash da chave de partição e vai direto para a partição física certa. Ele nunca escaneia a tabela inteira, então o tempo de resposta é aproximadamente constante quer a tabela tenha milhares ou bilhões de itens.
Leituras em microssegundos com o DAX
O DAX é um cache em memória totalmente gerenciado e compatível com o DynamoDB que fica na frente da sua tabela. Ele devolve leituras com consistência eventual em microssegundos — uma melhora de até 10x em relação a milissegundos — sem invalidação de cache para gerenciar. Não é adequado para cargas que precisam de leituras com consistência forte.
O número que seus usuários realmente enxergam
Milissegundos de um dígito é o que se mede no endpoint do DynamoDB. O que a sua aplicação experimenta é isso mais a rede, e a rede geralmente é a maior metade por larga margem.
Medido de uma máquina na Espanha em 2026-07-28, nove amostras por Região, mediana do handshake TCP para cada endpoint regional do DynamoDB. Isso é uma ida e volta, antes de um único byte de requisição ser enviado:
| Região | Mediana do handshake TCP |
|---|---|
| eu-central-1 (Frankfurt) | 46,6 ms |
| eu-south-2 (Espanha) | 49,1 ms |
| eu-west-1 (Irlanda) | 53,8 ms |
| us-east-1 (N. Virginia) | 113,6 ms |
| ap-northeast-1 (Tóquio) | 259,5 ms |
Uma máquina, um provedor, uma tarde, então leia isso como ordens de grandeza e não como um benchmark. Duas coisas aí valem de forma geral. Uma ida e volta transatlântica é mais de dez vezes a leitura que ela carrega, então nessa distância a latência do DynamoDB é um erro de arredondamento dentro da sua. E a Região geograficamente mais próxima da máquina não foi a mais rápida a partir dela: a eu-south-2 fica na Espanha e não mediu nada melhor que Frankfurt, porque quem decide é o roteamento, não a distância.
A versão prática disso é que colocar a computação junto da tabela ganha de qualquer ajuste de DynamoDB que você consiga fazer. Uma função Lambda na Região da tabela paga uma fração dos números acima; um notebook ou um job de CI em outro continente paga todos eles em cada conexão, o que é também por que a reutilização de conexão do SDK importa mais do que parece.
O que pode te deixar lento
- Scans e filtros — ler a tabela inteira é lento e caro; projete acesso baseado em chave em vez disso.
- Partições quentes — quando uma chave de partição atrai muito mais tráfego que sua parcela, as requisições contra ela sofrem throttle mesmo com a capacidade geral da tabela sobrando.
Bom design de chaves, e não mais hardware, é o que mantém o DynamoDB rápido.
Aprofunde-se
Leia query vs scan e evite uma partição quente. Baixe o DynoTable para ver quais leituras rodam como Query e quais como Scan.
Referências
- Fast NoSQL Key-Value Database — Amazon DynamoDB — AWS
- In-memory acceleration with DynamoDB Accelerator (DAX) — Amazon DynamoDB Developer Guide
- What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
- Core components of Amazon DynamoDB — Amazon DynamoDB Developer Guide
Verificado pela última vez em 2026-07-13 contra a documentação oficial da AWS vinculada acima.
Números de latência medidos em 2026-07-28 a partir de uma única máquina na Espanha com curl, nove requisições por Região, reportando a mediana de time_connect menos time_namelookup contra https://dynamodb.<region>.amazonaws.com. Duas execuções independentes concordaram dentro de 3 ms.