MongoDB vs DynamoDB: documento ou KV gerenciado?
MongoDB é um banco de dados de documentos flexível que você roda ou hospeda; DynamoDB é um store key-value e de documentos totalmente gerenciado da AWS com escala previsível.
MongoDB oferece querying rico, aggregation pipelines, índices secundários e um modelo de documento flexível, disponível self-hosted ou via Atlas. DynamoDB é serverless, escala de forma transparente e cobra por requisição ou capacidade, mas exige design cuidadoso de chaves e padrões de acesso antecipadamente, já que queries ad hoc são limitadas. MongoDB favorece flexibilidade de query; DynamoDB favorece escala sem gestão dentro da AWS.
| MongoDB | DynamoDB | |
|---|---|---|
| Modelo | Documento | Key-value / documento |
| Querying | Rico, ad hoc | Padrões de acesso por chave/índice |
| Ops | Self-host ou Atlas | Totalmente gerenciado (AWS) |
| Escala | Sharding | Automática, serverless |
| Melhor para | Queries flexíveis | Escala AWS-native, baixa ops |
Caso de uso e escala
MongoDB se adequa a apps que precisam de queries flexíveis e em evolução e aggregation, onde você aceita gerenciar a escala ou pagar pelo Atlas. DynamoDB se adequa a cargas AWS-native de alta escala com padrões de acesso conhecidos e desejo de zero ops de banco de dados, ao custo de disciplina de modelagem e lock-in de fornecedor.
Em CI
MongoDB roda como service container facilmente. DynamoDB tem o DynamoDB Local para testes offline, evitando bater na AWS real. Ambos se adequam a runners gerenciados, onde runners mais rápidos encurtam a inicialização do container ou do emulador local e as execuções de teste.
O veredito
Queries flexíveis e ad hoc e aggregation, portáveis entre nuvens: MongoDB. AWS-native, escala massiva com padrões de acesso previsíveis e ops mínima: DynamoDB. A decisão costuma depender do comprometimento com a nuvem e de se seus padrões de acesso são fixos o suficiente para a modelagem do DynamoDB.