SQL para DynamoDB: O Que Funciona, O Que Não Funciona e o Workbench

O DynamoDB é um armazenamento NoSQL de chave-valor, mas ele responde perguntas em formato de SQL mais do que as pessoas esperam — e bem menos do que esperam. Este é o mapa honesto: qual SQL-sobre-DynamoDB você realmente tem de fábrica, onde ele para, e as poucas formas de rodar as consultas de JOIN / GROUP BY / agregado que a superfície nativa não consegue expressar.

Dá para consultar o DynamoDB com SQL? A resposta curta

Em parte. O DynamoDB vem com o PartiQL, que as docs da AWS descrevem como "uma linguagem de consulta compatível com SQL, para selecionar, inserir, atualizar e excluir dados no Amazon DynamoDB". Então você pode escrever SELECT * FROM "Orders" WHERE OrderID = 100 e funciona.

Mas o PartiQL é uma superfície compatível com SQL sobre a API do DynamoDB, não um motor SQL. Ele fala a sintaxe; ele não adiciona poder de consulta relacional. A AWS é explícita ao dizer que "o Amazon DynamoDB suporta um subconjunto da linguagem de consulta PartiQL" (referência). No momento em que você recorre a um JOIN, um GROUP BY ou COUNT(*), você está fora do que o PartiQL consegue fazer — veja PartiQL vs SQL para a comparação completa recurso por recurso.

PartiQL: uma superfície compatível com SQL, não um motor SQL

O PartiQL mapeia instruções com cara de SQL nas mesmas operações de plano de dados que o SDK expõe. Um SELECT com igualdade de chave de partição compila para um Query; um SELECT sem ela compila para um Scan. Conforme a referência de SELECT da AWS:

Usar a instrução SELECT pode resultar em um full table scan se uma condição de igualdade ou IN com uma chave de partição não for fornecida na cláusula WHERE.

Então as mesmas regras de padrão de acesso que governam Query e Scan ainda se aplicam — o PartiQL apenas as esconde atrás de uma sintaxe familiar. Ele não adiciona planejador de consulta, joins, nem agregação baseada em conjuntos. Toda instrução colapsa para uma operação nativa:

Se uma operação não se reduz a um único Get/Query/Scan/Put/Update/Delete, o PartiQL simplesmente não consegue expressá-la. Tudo abaixo é uma consequência desse único fato.

O que o PartiQL cobre

O PartiQL do DynamoDB suporta quatro instruções de DML/consulta:

• SELECT — lê itens (compila para Query ou Scan)
• INSERT — adiciona um item (PutItem)
• UPDATE — modifica um item (UpdateItem)
• DELETE — remove um item (DeleteItem)

Ele também suporta transações e operações em lote. Uma leitura bem-formada mira a chave de partição com uma igualdade ou IN:

SELECT OrderID, Total
FROM "Orders"
WHERE OrderID IN [1, 2, 3] ORDER BY OrderID DESC

O ORDER BY é permitido, mas a referência da AWS restringe a chave de ordenação a "uma hash key ou uma sort key" — a chave de partição ou de ordenação, não colunas arbitrárias. Esse é o teto do que o SELECT do PartiQL aceita. Para instruções prontas para copiar e colar, veja exemplos de PartiQL.

O que o PartiQL não consegue fazer

Estas são as coisas que os desenvolvedores mais esperam de "SQL", e o PartiQL suporta nenhuma delas:

• Sem JOIN. A sintaxe de SELECT do PartiQL é um único FROM {{table}}[.{{index}}] — uma tabela ou um índice, nunca duas tabelas relacionadas por uma chave. Esse é o tradeoff do single-table-design: você modela para seus padrões de acesso de antemão porque a camada de consulta não consegue remodelar os dados depois.
• Sem GROUP BY. Não está na gramática; não há cláusula para agrupar linhas.
• Sem funções de agregação. A referência de funções do PartiQL lista exatamente uma função sob "Aggregate functions": SIZE, que retorna o tamanho de um atributo em bytes para um único item. Não há COUNT, SUM, AVG, MIN ou MAX através de linhas. A AWS afirma claramente: "Quaisquer funções SQL que não estejam nesta lista não são atualmente suportadas no DynamoDB."
• Sem LIKE, sem subqueries, sem UNION, sem funções de janela. A correspondência de padrões usa contains / begins_with; o resto não tem equivalente algum.

Então "receita total por cliente no mês passado" — um GROUP BY de uma linha em qualquer banco de dados relacional — não pode ser expresso no PartiQL. Você teria que escanear os dados para fora e agregar no código da aplicação.

A única forma de obter comportamento de JOIN / GROUP BY / agregado de verdade sobre dados do DynamoDB é uma ferramenta que rode um motor SQL real por cima dele. Há duas: o conector federado do Amazon Athena, e o SQL Workbench do DynoTable.

Como consultar o DynamoDB com SQL de verdade via Amazon Athena

A própria resposta da AWS para "SQL real sobre DynamoDB" é o conector DynamoDB do Amazon Athena, que "permite que o Amazon Athena se comunique com o DynamoDB para que você possa consultar suas tabelas com SQL". Como o Athena é um motor SQL completo, isso de fato te dá JOIN e agregados — o passo a passo da AWS se chama "Access, query, and join Amazon DynamoDB tables using Athena".

A pegadinha é a configuração e o custo:

• É um conector federado baseado em Lambda que você implanta na sua conta (via o console do Athena ou o Serverless Application Repository), conectado através do AWS Glue para schema e despejando resultados em um bucket S3 (docs do conector).
• Por baixo dos panos ele ainda usa as operações de API Query e Scan do DynamoDB. A AWS avisa que "consultas que usam scans podem consumir um grande número de unidades de capacidade de leitura (RCUs)", então uma consulta analítica sobre uma tabela grande lê — e tarifa — muitos itens (custos do conector). Use a calculadora de tamanho de item para estimar o que uma consulta pesada em scan vai custar.
• Operações de escrita como INSERT INTO não são suportadas pelo conector.

O Athena é a ferramenta certa para análises agendadas e dashboards de BI. Ele é pesado demais para o caso do dia a dia "só preciso fazer join de duas tabelas e dar uma olhada no resultado" — essa é a lacuna que a próxima seção preenche.

DynoTable SQL Workbench: SQL dentro das regras de padrão de acesso do DynamoDB

O SQL Workbench do DynoTable roda SQL de verdade — JOIN, GROUP BY, COUNT/SUM/AVG — contra suas tabelas DynamoDB ao vivo a partir de um cliente desktop, sem Lambda, Glue ou S3 para montar. Ele materializa as linhas através do runtime real de Query/Scan do DynamoDB, depois roda seu SQL completo num motor em memória por cima:

-- Roda no DynoTable Workbench (NÃO no PartiQL):
SELECT c.country, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
INNER JOIN customers c ON o.customerId = c.PK
GROUP BY c.country
ORDER BY revenue DESC

A parte "dentro das regras de padrão de acesso do DynamoDB" importa. O Workbench não finge que o DynamoDB é Postgres — ele ainda lê através de Query/Scan por baixo dos panos, então você fica ciente do que cada consulta custa, e ele impõe o modelo de acesso do DynamoDB em vez de escondê-lo:

• Apenas INNER JOIN e LEFT JOIN — o atributo de destino do ON precisa ser uma chave de partição ou chave de partição de GSI. Sem RIGHT / FULL / CROSS / join por vírgula.
• Ainda sem self-joins, sem subqueries, sem tabelas derivadas, sem funções de janela.
• Joins e projeções operam sobre atributos escalares.

Se você só precisa compor as condições e expressões de chave para a API bruta — não uma instrução SQL completa — o DynamoDB Expression Builder gera a FilterExpression / KeyConditionExpression correta sem a superfície do PartiQL de jeito nenhum.

Se seu objetivo é um cliente SQL de DynamoDB para explorar, depurar e analisar tabelas, o Workbench preenche essa lacuna — e o resto do DynoTable é uma GUI de DynamoDB completa em torno dele.

Experimente o DynoTable para rodar SQL de verdade contra suas próprias tabelas.

FAQ

Dá para rodar SQL no DynamoDB? Você pode rodar PartiQL, um subconjunto compatível com SQL (SELECT/INSERT/UPDATE/DELETE por chave). Para SQL completo — JOIN, GROUP BY, agregados — você precisa de um motor SQL por cima: o conector DynamoDB do Amazon Athena, ou o SQL Workbench do DynoTable.

O PartiQL do DynamoDB suporta JOIN? Não. A sintaxe de SELECT do PartiQL tem uma única tabela ou índice no FROM e nenhuma gramática de join. Joins exigem um motor sobreposto ao DynamoDB.

O PartiQL suporta GROUP BY ou agregados como COUNT e SUM? Não. Não há cláusula GROUP BY, e a única função "agregada" é SIZE (o tamanho em bytes de um atributo para um item). COUNT, SUM, AVG, MIN e MAX através de linhas não são suportados.

O DynamoDB é SQL ou NoSQL? NoSQL — um armazenamento de chave-valor e documentos. O PartiQL adiciona uma linguagem de consulta compatível com SQL por cima, mas o DynamoDB não tem motor relacional, joins ou agregados.

O PartiQL é bom para consultas ad-hoc? Para buscas baseadas em chave, sim. Para consultas analíticas ad-hoc (contagens, rollups, joins), não — o PartiQL não consegue expressá-las, e SELECTs sem restrição silenciosamente viram full table scans.

Existe um cliente SQL de DynamoDB que lida com JOIN e GROUP BY? Sim — o SQL Workbench do DynoTable roda JOIN/GROUP BY/agregados contra tabelas ao vivo do desktop, e o Amazon Athena faz isso via um conector federado que você implanta na sua conta AWS.