Como Consultar o DynamoDB com IA (Linguagem Natural)

"Me mostra os pedidos que falharam na semana passada" é uma frase na sua cabeça e uma KeyConditionExpression com mapas de placeholders na rede. Fechar essa lacuna é o que "consultar o DynamoDB com IA" realmente significa — porque a própria API do DynamoDB não tem endpoint de linguagem natural. Cada requisição continua sendo expressões ou ; a IA fica na camada de ferramentas, traduzindo a sua intenção para elas.

Essa tradução pode ser genuinamente ótima ou silenciosamente perigosa, dependendo de uma coisa: se o modelo consegue ver o seu schema real. Este guia cobre as três configurações que funcionam e onde cada uma quebra.

Como consulto o DynamoDB usando linguagem natural?

Três opções reais: pedir a um LLM genérico para rascunhar PartiQL e rodar você mesmo (rápido, mas o modelo está adivinhando seus nomes de atributo), conectar um agente de IA ao DynamoDB por meio de um servidor MCP para que ele possa inspecionar e consultar de verdade, ou usar um cliente DynamoDB com um assistente ciente do schema embutido — o chat de IA do DynoTable transforma linguagem natural em PartiQL ou SQL contra o seu schema indexado real, computa agregações exatas de tabela inteira e prepara qualquer escrita para a sua revisão.

Opção 1: PartiQL rascunhado por LLM, executado por você

A versão sem configuração: descreva a consulta para qualquer modelo capaz, receba PartiQL de volta, rode no editor de PartiQL do console ou via CLI:

aws dynamodb execute-statement \
  --statement "SELECT * FROM \"Orders\" WHERE PK = 'ORDER#1001'"

Funciona — e falha de três maneiras previsíveis:

O modelo não consegue ver a sua tabela. Ele vai inventar com confiança nomes de atributo e formatos de chave (orderId quando o seu é PK = ORDER#<id>). Você acaba depurando schema alucinado em vez de escrever a consulta.
Os limites do PartiQL continuam valendo. Um SELECT lê exatamente uma tabela, e um WHERE que não fixa uma chave vira um scan de tabela inteira — silenciosamente caro, exatamente como se você mesmo o tivesse escrito. O modelo raramente te avisa; PartiQL vs SQL explica o que a superfície SQL compra e o que não compra.
Colar schema ou dados em um chatbot é uma decisão de governança de dados. Itens de amostra em um prompt são dados de produção saindo da sua fronteira.

Bom para consultas pontuais em um schema que você consegue colar de memória; frágil como fluxo de trabalho.

Opção 2: um agente de IA conectado via MCP

A correção estrutural para "o modelo não consegue ver a sua tabela" é dar ao agente ferramentas em vez de um schema colado no prompt. O Model Context Protocol (MCP) faz exatamente isso: um servidor MCP expõe operações do DynamoDB como ferramentas tipadas, e qualquer agente compatível com MCP (Claude, assistentes de IDE, agentes customizados) pode listar tabelas, inspecionar chaves e rodar consultas com resultados reais realimentando a conversa.

Cobrimos a configuração completa — e as questões de consentimento, escopo e segurança de escrita que vêm com deixar um agente tocar um banco de dados — em Usando o DynamoDB com um servidor MCP. O próprio DynoTable inclui um: ele pode expor ferramentas controladas, restritas a loopback, para agentes externos, com consentimento e escopos por conexão.

Esta é a arquitetura certa quando o agente é o produto — um bot de suporte, um assistente interno de Slack. Para o trabalho interativo do dia a dia, ela ainda te deixa montando agente, servidor e credenciais por conta própria.

Opção 3: um assistente ciente do schema no seu cliente DynamoDB

O assistente embutido do DynoTable é a versão integrada: ele vive ao lado das suas tabelas (⌘;), e lê o seu schema indexado — as tabelas sob o profile ativo, suas chaves e índices, os caminhos de atributo e tipos descobertos pela indexação de tabela, até valores de amostra — então "filtra isso para a semana passada" resolve contra os seus nomes de atributo reais, não um chute. Digite @ para referenciar uma @table, @column ou @gsi explicitamente.

O chat de IA do DynoTable encaixado ao lado de uma aba de tabela: uma pergunta em linguagem natural, a consulta gerada e o resultado abrindo como uma view.

O que ele faz com uma pergunta, segundo o catálogo de capacidades:

Escreve a consulta para você — PartiQL somente leitura, ou SQL do Workbench quando a pergunta precisa de JOIN / GROUP BY / agregações (a análise que a API do DynamoDB não tem) — e propõe o resultado como um chip em que você clica para abrir como uma aba de verdade.
Computa respostas exatas de tabela inteira. Peça uma contagem, soma, média ou quebra por grupo e ele lê cada item correspondente, não uma página amostrada — "quantos pedidos no mês passado?" reflete a tabela real. Ele pode remodelar a mesma passada em um arquivo de export transformado.
Prepara cada escrita. Peça para ele corrigir uma linha e a mudança cai na área de preparação como um diff revisável — o assistente não pode escrever no DynamoDB diretamente, excluir uma tabela em lote ou alterar a estrutura de tabelas, em nenhum modo de permissão. Você revisa, você faz commit.
Pergunta antes de gastar o seu dinheiro. Leituras que chegam à AWS e custam capacidade são controladas por permissão (Manual / Auto / Full Auto, por profile), e cada decisão controlada cai em um log de auditoria local e sempre ativo.

O modelo de confiança importa tanto quanto as features: o assistente roda com suas próprias credenciais do AWS Bedrock, falando diretamente com o Bedrock na sua conta — prompts, schema e dados de tabela nunca passam pelos servidores do DynoTable, e a inferência é cobrada de você nas tarifas do próprio Bedrock, sem markup. Resultados de ferramentas são tratados como dados não confiáveis, então uma linha contendo "ignore as instruções anteriores" não consegue sequestrar o agente.

O que a IA NÃO muda no DynamoDB

Qualquer camada de IA honesta herda a física do banco:

Padrões de acesso continuam mandando. "Where status = X" sobre um atributo que não é chave é um scan filtrado não importa quem escreva — o modelo só digita a consulta cara mais rápido. Se uma pergunta continua forçando scans, a correção é modelagem (um GSI, uma chave de classificação melhor), não um prompt melhor.
Leituras custam capacidade de verdade. Uma agregação exata de tabela inteira é uma leitura de tabela inteira. Ferramentas boas controlam isso e avisam; a calculadora de preços te diz o que uma passada completa custa antes de você aprovar.
O determinismo tem seu lugar. Para uma consulta que você vai rodar para sempre em produção, monte a expressão à mão uma vez no Expression Builder e envie os mapas exatos de nomes/valores — IA é para exploração, o builder é para o código que você commita.

FAQ

Posso consultar o DynamoDB em linguagem natural? Não contra a API em si — o DynamoDB só fala expressões e PartiQL. Mas uma camada de IA pode traduzir: um LLM rascunhando PartiQL, um agente conectado via MCP, ou um assistente ciente do schema como o do DynoTable, que gera e roda a consulta contra o seu schema real.

O DynamoDB tem uma feature de consulta com IA embutida? A API do DynamoDB não tem endpoint de linguagem natural. Qualquer consulta com IA que você tiver vem da camada de ferramentas por cima — e é por isso que o modelo de segurança dessa ferramenta (leituras controladas, escritas preparadas, suas próprias credenciais) é o que deve ser avaliado.

É seguro deixar a IA perto de dados de produção? É uma questão de permissões. Procure por: leituras controladas por aprovação explícita, escritas que caem em uma área de preparação revisável em vez de executar diretamente, um log de auditoria, e inferência em credenciais que você controla. O assistente do DynoTable atende aos quatro; um chatbot com seus dados colados não atende a nenhum.

A IA consegue fazer join de tabelas ou GROUP BY? Não via a API do DynamoDB — não existe engine para isso. O assistente do DynoTable responde essas perguntas pelo seu SQL do Workbench somente leitura (JOIN, GROUP BY e agregações de verdade dentro das regras de padrão de acesso do DynamoDB), que também é onde as perguntas de count/sum/média desembocam.

Quanto custa? Dois medidores: capacidade de leitura do DynamoDB para o que as consultas tocarem (o assistente pergunta antes de leituras controladas), e inferência do Bedrock cobrada na sua própria conta AWS — o DynoTable não adiciona markup e não faz proxy de nada.

Faça sua próxima pergunta em linguagem natural — baixe o DynoTable, aponte a IA para o seu próprio Bedrock e mantenha cada escrita atrás de uma revisão.