DynamoDB vs Redshift

O DynamoDB e o Amazon Redshift raramente são alternativas. O DynamoDB é um banco de dados operacional — leituras e escritas em milissegundos de um dígito contra chaves conhecidas, servindo tráfego de aplicação ao vivo. O Redshift é "a fully managed, petabyte-scale data warehouse service in the cloud," construído para varrer e agregar grandes conjuntos de dados para relatórios e analytics. Equipes que rodam ambos são o caso normal, e a AWS oferece uma integração gerenciada para mover dados em uma direção entre eles.

Você deve usar DynamoDB ou Redshift?

Use o DynamoDB para os dados ao vivo da aplicação: pedidos sendo feitos, sessões sendo lidas, registros buscados por chave. Use o Redshift quando alguém precisa fazer perguntas sobre o conjunto de dados inteiro — receita por região e mês, retenção de coorte, um dashboard juntando várias fontes. A pergunta "qual dos dois" normalmente se resolve em "DynamoDB para o caminho de escrita, Redshift para os analistas," com a integração zero-ETL no meio.

DynamoDB vs Redshift em resumo

Característica	DynamoDB	Redshift
Carga de trabalho	Operacional (estilo OLTP) — leituras e escritas de alto volume por chave	Analítica — varreduras e agregações sobre grandes conjuntos de dados
Modelo de dados	Itens NoSQL sem schema de até 400 KB; atributos variam por item	Tabelas relacionais com colunas declaradas, chaves de distribuição e chaves de ordenação
Linguagem de consulta	API nativa (`GetItem`, `Query`, `Scan`, …) mais PartiQL	SQL completo, com as ferramentas de BI e SQL que isso implica
Joins e agregações	Sem joins no servidor; agregação não é uma operação no servidor	Joins, window functions, `GROUP BY` e o restante do SQL analítico
Padrão de acesso	Projetado em torno de chaves conhecidas; scans são a exceção cara	Projetado para varrer — ler muitas linhas é o caso normal
Latência	Milissegundos de um dígito por requisição	Segundos a minutos por consulta analítica, sobre muito mais dados
Escalabilidade	Serverless; partições gerenciadas pela AWS	Workgroups serverless ou clusters provisionados; capacidade dimensionada para a carga de consulta
Atualidade	Read-your-write sob demanda	Tão atual quanto o que o carrega — a integração zero-ETL aterrissa atualizações a cada 15–30 minutos
Modelo de preço	Por requisição ou capacidade provisionada, mais armazenamento	Capacidade de computação mais armazenamento; warehouses serverless ociosos não são cobrados por computação

Quando o DynamoDB é a melhor escolha

Tráfego de aplicação ao vivo. Leituras e escritas previsíveis em milissegundos de um dígito contra chaves conhecidas, em qualquer taxa de requisição.
Schema que varia por item. Itens heterogêneos em uma tabela são normais no DynamoDB; um armazém quer colunas declaradas.
Operações serverless. Nenhum cluster para dimensionar, corrigir ou pausar.
Caminhos intensivos em escrita. O DynamoDB absorve escritas de alto volume como seu trabalho principal; um armazém é otimizado para carga em massa e leitura.

Quando o Redshift é a melhor escolha

Perguntas que cruzam a tabela inteira. Agregar um ano de pedidos é uma varredura por natureza, que é exatamente o padrão de acesso que o DynamoDB pede para você evitar e para o qual o Redshift é projetado.
Joins entre muitas fontes. Armazéns fazem join. O DynamoDB não tem join no servidor.
Ferramentas de BI. O Redshift fala SQL sobre JDBC/ODBC, então encaixa em dashboards existentes e nas "same SQL-based tools and business intelligence applications that you use today."
Análise que não pode perturbar a produção. Rodar analytics contra uma cópia replicada mantém a carga fora da tabela que serve seus usuários.

Usando os dois juntos

O padrão padrão é unidirecional: o DynamoDB serve a aplicação, uma cópia aterra no Redshift, analistas trabalham na cópia. A AWS oferece duas rotas — o comando COPY mais antigo, que carrega diretamente "from Amazon S3 or Amazon DynamoDB into Amazon Redshift," e a integração zero-ETL gerenciada, que mantém a cópia atualizada por conta própria.

O que a integração zero-ETL realmente faz

"Zero-ETL" sugere uma visão ao vivo. Não é uma, e os detalhes importam antes de você projetar um dashboard em torno dela.

É um pipeline de replicação em timer. A AWS é precisa: "On activation, the integration exports the full DynamoDB table to populate the Amazon Redshift database." Depois "the zero-ETL integration then incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." Então os dados no Redshift estão com até meia hora de atraso. Isso serve para relatórios diários e está errado para qualquer coisa que um usuário deva ver refletir sua última ação.

Point-in-time recovery é obrigatório — e agora o motivo é óbvio. O pré-requisito é declarado claramente: "A zero-ETL integration between Amazon DynamoDB and Amazon Redshift requires your source DynamoDB table to have Point-in-time recovery (PITR) enabled." A AWS documenta o requisito em um lugar e o mecanismo em outro, e não os conecta, mas a política baseada em recursos que você deve anexar entrega o jogo — ela concede a redshift.amazonaws.com a ação dynamodb:ExportTableToPointInTime. A integração é construída sobre a maquinaria de exportação do DynamoDB para o S3, e essa maquinaria lê do backup contínuo. Sem PITR, sem exportação, sem integração.

Isso tem uma consequência de orçamento que as pessoas encontram tarde: habilitar PITR em uma tabela grande é uma cobrança permanente sobre o tamanho da tabela, incorrida para o pipeline de analytics em vez de para recuperação. Precifique a integração como "Redshift mais PITR," não como Redshift sozinho — a calculadora de preços do DynamoDB gratuita dimensiona o lado de armazenamento disso antes de você se comprometer.

Duas restrições que bloqueiam tabelas existentes. Ambas são limitações documentadas, e ambas são incômodas de corrigir depois do fato:

"The DynamoDB table and Amazon Redshift cluster need to be in the same Region." Um armazém consolidando várias Regiões não pode puxá-las todas por este caminho.
"The source DynamoDB table must be encrypted with either an Amazon-owned or Customer-managed AWS KMS key. Amazon managed encryption is not supported for the source DynamoDB table." Tabelas criadas com criptografia gerenciada pela AWS precisam ter suas configurações de criptografia alteradas antes que uma integração possa ser criada.

Onde o formato dos seus dados morde. Itens do DynamoDB são heterogêneos por design; tabelas de armazém têm colunas. Um design de tabela única guardando vários tipos de entidade sob uma convenção de chave de partição não vira um star schema limpo por ser replicado. Planeje trabalho de modelagem no Redshift depois que os dados aterrissarem — a integração remove o pipeline, não o design de schema.

Quando você ainda não precisa de um armazém

Nem toda agregação é um problema de analytics. Uma grande parte de "deveríamos colocar isso no Redshift" começa como uma pergunta — quantos itens estão neste estado, qual é o total para este cliente, quais chaves de partição dominam — feita ocasionalmente, por um engenheiro, contra uma tabela.

O SQL Workbench do DynoTable responde a essa classe de pergunta diretamente contra o DynamoDB, sob demanda: SQL real com COUNT, SUM, AVG, MIN, MAX, GROUP BY, HAVING e DISTINCT, mais INNER/LEFT JOIN. O posicionamento é deliberadamente estreito — SQL dentro das regras de padrões de acesso do DynamoDB. É um único SELECT; não há CTEs, nem UNION, nem window functions, nem subconsultas escalares; um alvo de join precisa ser uma chave de partição ou uma chave de partição de GSI. Os resultados são transmitidos com um badge parcial e ficam exatos quando a consulta roda até o fim, e ler os dados ainda custa as leituras que custa.

Isso não substitui um armazém, e os limites acima são o limite honesto. Mas é uma resposta mais rápida do que um pipeline de replicação, uma cobrança de PITR e um design de schema — e te diz se a pergunta valia um armazém antes de você construir um. Rodar consultas do Workbench é um recurso pago; o editor e o autocomplete são gratuitos. 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 Redshift pode substituir o DynamoDB?

Não, não para tráfego de aplicação. O Redshift é um armazém de dados construído para varrer e agregar; não é projetado para servir buscas por chave de alto volume com latência em milissegundos de um dígito. Os dois rodam lado a lado, com o DynamoDB servindo a aplicação e uma cópia replicada no Redshift servindo analytics.

Quão atualizados estão os dados do DynamoDB no Redshift?

Com a integração zero-ETL, com até cerca de 30 minutos de atraso. A AWS documenta que, após a exportação completa inicial, ela "incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." Trate como relatórios quase em tempo real, não como uma visão ao vivo.

Por que a integração zero-ETL exige PITR?

Porque é construída sobre a exportação point-in-time do DynamoDB. A política baseada em recursos que a integração precisa concede ao Amazon Redshift a ação dynamodb:ExportTableToPointInTime, e essa exportação lê do backup contínuo que o PITR mantém. Habilitar PITR é, portanto, um custo real e contínuo da integração.

Relacionados

Aprenda quando usar o DynamoDB e por que scans são caros.
Compare DynamoDB e PostgreSQL para a questão relacional operacional.
Modele padrões de acesso antecipadamente com single-table design.
Dimensione o lado de armazenamento e capacidade com a calculadora de preços do DynamoDB gratuita.
Baixe o DynoTable para consultar e agregar suas tabelas do DynamoDB diretamente.

Referências

Verificado pela última vez em 2026-08-02 contra o AWS Redshift Management Guide oficial e o DynamoDB Developer Guide.