DynamoDB vs Amazon RDS
DynamoDB e Amazon RDS são ambos bancos de dados gerenciados da AWS, mas representam dois mundos diferentes. O DynamoDB é um banco de dados NoSQL serverless chave-valor e de documentos projetado em torno de padrões de acesso conhecidos e escala horizontal. O Amazon RDS é um serviço gerenciado para rodar mecanismos relacionais baseados em instâncias — MySQL, PostgreSQL, MariaDB, SQL Server, Oracle e Db2 — com SQL completo, joins e schemas impostos.
Você deve usar DynamoDB ou RDS?
Escolha DynamoDB para cargas de trabalho operacionais de alta escala com acesso previsível baseado em chave, onde você quer escalabilidade serverless e nenhuma instância para gerenciar. Escolha Amazon RDS quando você precisa de SQL completo — joins, consultas ad-hoc, transações entre tabelas normalizadas — em um mecanismo relacional familiar e seus dados cabem em uma instância que você pode escalar verticalmente com réplicas de leitura. Flexibilidade de consulta versus escala sem esforço é o trade central.
DynamoDB vs Amazon RDS em resumo
| Característica | DynamoDB | Amazon RDS |
|---|---|---|
| Modelo de dados | NoSQL chave-valor e de documentos; schema flexível por item, itens de até 400 KB | Relacional — tabelas, linhas e colunas com um schema imposto, no mecanismo que você escolher |
| Linguagem de consulta | API nativa (GetItem, Query, Scan) mais PartiQL, uma linguagem compatível com SQL | SQL completo do mecanismo subjacente (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, Db2) |
| Joins e relações | Sem operador JOIN; a AWS recomenda desnormalizar em torno dos padrões de acesso | Joins relacionais completos, chaves estrangeiras e restrições entre tabelas |
| Índices | Índices secundários globais e locais em uma chave alternativa | Os tipos de índice do mecanismo (B-tree, hash e específicos do mecanismo), mais índices parciais/de expressão em alguns mecanismos |
| Consistência | Consistência eventual por padrão; leituras com consistência forte por requisição; transações ACID | Consistência forte por padrão; transações ACID completas de múltiplas instruções |
| Modelo de escala | Horizontal — particionamento automático; o modo serverless On-Demand escala para cima e para baixo (até zero) | Vertical — uma instância provisionada que você redimensiona, mais réplicas de leitura para escalar leituras |
| Provisionamento / operação | Serverless; nenhuma instância para dimensionar ou corrigir | Baseado em instâncias; você escolhe a classe e o armazenamento, a AWS gerencia correções, backups e failover (Multi-AZ opcional) |
| Modelo de preço | Pagamento por requisição (On-Demand) ou capacidade provisionada mais armazenamento; escala até zero quando ocioso | Horas de instância para a classe de BD mais armazenamento (e I/O em algumas opções), cobrado enquanto a instância roda |
| Cargas de trabalho ideais | Apps operacionais de alta escala com acesso por chave conhecido (carrinhos, sessões, eventos, placares) | Cargas relacionais e analíticas que precisam de joins, consultas ad-hoc e forte integridade dos dados |
Quando o DynamoDB é a melhor escolha
- Seus padrões de acesso são conhecidos e baseados em chave. Projetar as chaves em torno das suas leituras dá latência consistente de milissegundos de um dígito, quer você tenha centenas ou centenas de milhões de usuários.
- Você quer serverless sem instâncias. A capacidade On-Demand não tem nada para dimensionar ou corrigir e escala até zero quando ociosa — nenhuma instância rodando o tempo todo.
- Você precisa escalar escritas horizontalmente. O DynamoDB particiona automaticamente; você não adiciona ferramentas de sharding como faria para escalar um único primário relacional.
- Sua carga de trabalho é orientada a itens (perfis, sessões, carrinhos, eventos) em vez de uma teia de tabelas com joins.
Quando o Amazon RDS é a melhor escolha
- Você precisa de SQL completo e joins. O RDS roda mecanismos relacionais reais com joins, agregações, chaves estrangeiras e consultas ad-hoc entre tabelas normalizadas.
- Seus padrões de acesso continuam evoluindo. Um schema relacional com consulta flexível se adapta a novas perguntas sem redesenhar as chaves.
- Você quer um mecanismo familiar. MySQL, PostgreSQL, MariaDB, SQL Server, Oracle e Db2 permitem que as equipes reutilizem habilidades, ferramentas e SQL existentes.
- Seu conjunto de dados cabe em uma instância escalada verticalmente com réplicas de leitura, e o tráfego estável e intensivo em consultas combina com uma instância sempre ativa.
Trabalhando com o DynamoDB
Se o DynamoDB é o lado certo da divisão, o DynoTable é um cliente
desktop nativo para ele em macOS, Windows e Linux. Ele lê sua cadeia de
credenciais padrão da AWS, então seus dados permanecem no DynamoDB sem nada para
migrar. Fundamental para equipes vindas do RDS, seu SQL Workbench expressa
consultas em formato relacional — joins, GROUP BY, agregações — dentro das
regras de padrões de acesso do DynamoDB, compilando-as para as próprias
operações Query/Scan do DynamoDB, e seu assistente de IA roda nas suas
próprias credenciais do AWS Bedrock.
Se você sente falta de escrever SQL, os guias SQL para DynamoDB e PartiQL vs SQL explicam o que se traduz e o que não, e o guia de JOIN no DynamoDB cobre a modelagem de relações sem um join nativo. O DynamoDB Expression Builder gratuito gera condições de chave, filtros e expressões de atualização corretas nos formatos SDK, CLI e PartiQL. O DynoTable é um aplicativo comercial de código fechado; esta página descreve o que ele faz, não como ele é construído.
FAQ
O DynamoDB pode substituir o Amazon RDS?
Para algumas cargas de trabalho, sim. Se seus padrões de acesso são previsíveis e baseados em chave, o DynamoDB pode substituir uma instância RDS e remover a maior parte do trabalho de escalabilidade e correção. Ele é uma má escolha quando você depende de joins, consultas relacionais ad-hoc ou uma superfície de consulta em constante mudança — os pontos fortes do RDS. Muitas equipes rodam ambos: RDS para trabalho relacional, DynamoDB para acesso por chave de alto throughput.
O DynamoDB suporta SQL e joins como o RDS?
O DynamoDB suporta PartiQL — uma linguagem compatível com SQL para SELECT, INSERT, UPDATE e DELETE — mas não tem operador JOIN; a AWS recomenda desnormalizar em vez disso. Os mecanismos por trás do RDS suportam SQL completo, incluindo joins entre tabelas. Veja Joins no DynamoDB para saber como modelar relações sem um.
O DynamoDB é mais barato que o RDS?
Depende da carga de trabalho, então modele os dois. O DynamoDB cobra por requisição (ou capacidade provisionada) mais armazenamento e escala até zero quando ocioso, o que combina com tráfego irregular ou de baixa linha de base. O RDS cobra horas de instância para uma classe em execução mais armazenamento, o que pode ser mais econômico para cargas de trabalho estáveis e intensivas em consultas. Estime contra seus padrões de acesso reais antes de decidir.
Relacionados
- Aprenda SQL para DynamoDB, PartiQL vs SQL e joins no DynamoDB.
- Modele dados em torno de padrões de acesso com como modelar dados no DynamoDB.
- Construa consultas rapidamente com o DynamoDB Expression Builder gratuito.
- Baixe o DynoTable para macOS, Windows ou Linux.
Verificado pela última vez em 2026-07-12 contra a documentação oficial da AWS para DynamoDB e Amazon RDS. Amazon RDS e DynamoDB são serviços da Amazon Web Services; referenciados aqui apenas para identificação.