RDS, Aurora ou DynamoDB: qual banco de dados gerenciado escolher (e os equivalentes em Azure e GCP)

Depois de decidir hospedagem e como rodar a API em container, chega a pergunta que costuma ser adiada ate o ultimo momento: qual banco de dados gerenciado usar? A pergunta certa nao e "qual e melhor", e "qual encaixa no seu modelo de dados, no seu padrao de acesso e no que o seu time sabe operar".

1. RDS vs Aurora: a diferenca que a documentacao nao deixa obvia

Os dois sao bancos relacionais gerenciados na AWS, mas resolvem problemas diferentes:

• RDS: roda o motor relacional "padrao" (PostgreSQL, MySQL, MariaDB, SQL Server ou Oracle) gerenciado pela AWS — backup automatico, patch e failover basico resolvidos, mas o motor por baixo e o mesmo Postgres ou MySQL que voce rodaria em qualquer outro lugar. Mais previsivel e mais portavel.
• Aurora: banco proprietario da AWS compativel com o protocolo do MySQL ou do PostgreSQL, mas com uma camada de armazenamento distribuido proprio. Na pratica isso significa failover mais rapido, ate 15 replicas de leitura com replicacao quase instantanea, e a opcao de escala automatica via Aurora Serverless v2. O preco dessa performance e um lock-in maior: mesmo "falando" o protocolo Postgres/MySQL, voce nao pode simplesmente exportar o storage para rodar em outro lugar sem migracao.

Para a maioria dos projetos pequenos e medios, comecar com RDS resolve bem e mantem a porta aberta para trocar de provedor depois. Aurora comeca a compensar quando ha necessidade real de alta disponibilidade com failover rapido, muita leitura em paralelo, ou crescimento de trafego dificil de prever.

2. DynamoDB: quando realmente faz sentido

DynamoDB e um banco NoSQL gerenciado, do tipo chave-valor/documento, com latencia de milissegundos previsivel mesmo em alta escala de escrita. A diferenca central em relacao ao RDS/Aurora nao e "melhor ou pior", e o modelo mental: em vez de desenhar tabelas e depois escrever queries, no DynamoDB voce precisa desenhar o padrao de acesso (quais consultas vao existir) antes de criar a tabela. Migrar um schema relacional direto para o DynamoDB sem esse redesenho quebra a maioria dos casos de uso reais.

DynamoDB costuma valer a pena para: contadores de alta frequencia, sessao de usuario, carrinho de compras, catalogos consultados quase sempre pela mesma chave, ou cenarios de IoT com volume alto de escrita e leitura simples. Para relatorios com joins complexos ou consultas ad-hoc variadas, um banco relacional ainda resolve melhor.

3. Framework de decisao

1. Voce ja tem um modelo relacional com joins complexos e ainda nao sabe todos os padroes de consulta que vai precisar? Comece com RDS PostgreSQL ou MySQL. E a opcao mais previsivel e reversivel.
2. Precisa de alta disponibilidade com failover rapido e muita leitura em paralelo, e o orcamento comporta? Aurora resolve, aceitando o lock-in do storage proprietario em troca da performance.
3. Tem escrita massiva, padrao de acesso simples e bem definido (busca por chave, nao por consulta variada) e latencia previsivel e critica? DynamoDB, mas desenhe as chaves de particao e consulta antes de criar a tabela, nao depois.
4. Nao comece por NoSQL so porque "escala melhor". Para a maioria dos projetos pequenos essa vantagem e prematura e custa mais em redesenho de modelo de dados do que economiza em infraestrutura.

4. Equivalentes em Azure e Google Cloud

Azure

• Azure SQL Database: equivalente ao RDS — banco relacional gerenciado (SQL Server, com opcao de compatibilidade PostgreSQL/MySQL via servicos irmaos), previsivel e portavel.
• Cosmos DB: equivalente ao DynamoDB, mas com mais flexibilidade de modelo de dados (documento, chave-valor, grafo, column-family) e niveis de consistencia ajustaveis — mais opcoes, tambem mais decisao de configuracao antes de usar bem.

Google Cloud

• Cloud SQL: equivalente ao RDS — PostgreSQL, MySQL ou SQL Server gerenciado, mesma logica de previsibilidade e portabilidade.
• Firestore: NoSQL orientado a documentos, forte para aplicacoes web e mobile com sincronizacao em tempo real.
• Bigtable: mais proximo do DynamoDB em proposito — alta escala, baixa latencia, usado em cenarios de series temporais, IoT e analytics de grande volume.

5. Erros comuns

• Migrar um schema relacional direto para o DynamoDB (ou Cosmos DB, ou Bigtable) sem redesenhar o padrao de acesso antes.
• Escolher Aurora achando que e "so Postgres com mais recursos", sem considerar o lock-in do storage proprietario.
• Configurar o modo de capacidade errado no DynamoDB (provisionado vs sob demanda) e ser surpreendido por throttling ou por custo acima do esperado.
• Nao configurar backup automatico e recuperacao point-in-time desde o inicio, tratando isso como algo para "configurar depois".
• Escolher NoSQL antes de saber os padroes de consulta reais da aplicacao, so por achar que "escala melhor" no papel.

6. Checklist antes de escolher

1. Liste os padroes de consulta reais que a aplicacao vai precisar, nao so o modelo de dados inicial.
2. Se o modelo tem joins complexos ou consultas variadas, comece relacional (RDS ou Cloud SQL/Azure SQL).
3. Se decidir por NoSQL (DynamoDB, Cosmos DB, Firestore, Bigtable), desenhe as chaves de particao e consulta antes de criar a primeira tabela.
4. Configure backup automatico e teste ao menos uma restauracao antes de considerar o ambiente pronto para producao.
5. Revise o modo de capacidade/cobranca (provisionado vs sob demanda) e simule o custo na calculadora oficial da cloud escolhida.
6. Documente por que o banco foi escolhido, para nao repetir a discussao quando o projeto crescer.

O hub de Cloud reune os demais artigos deste cluster: como escolher entre AWS, Azure e Google Cloud, hospedagem de site estatico passo a passo e ECS, EKS ou Fargate.

Perguntas frequentes

Aurora e so um Postgres mais rapido? Nao exatamente. Aurora e compativel com o protocolo do Postgres ou MySQL, mas usa uma camada de armazenamento proprietaria da AWS, o que traz mais performance e failover mais rapido em troca de mais lock-in.

Posso migrar um banco relacional existente direto para o DynamoDB? Nao sem redesenho. DynamoDB exige desenhar o padrao de acesso antes de criar a tabela — migrar um schema relacional sem esse passo costuma quebrar consultas que antes eram triviais com joins.

Qual e o equivalente mais proximo do DynamoDB fora da AWS? Cosmos DB na Azure e o mais flexivel em modelo de dados; Bigtable no Google Cloud e o mais proximo em proposito de alta escala e baixa latencia.