O ChatGPT consegue escrever consultas SQL para o meu banco de dados específico?

Pare tudo o que está fazendo. A promessa é sedutora: colar o CREATE TABLE no chat, pedir um relatório mirabolante e receber o SQL pronto para colar no Workbench ou no DBeaver. Para o analista de dados cansado de digitar INNER JOIN ou o desenvolvedor júnior travado na terceira tabela de relacionamento, isso soa como salvação. Mas, na prática, o ChatGPT realmente entende a lógica de negócio por trás daquele schema bagunçado que você herdou, ou ele apenas decora sintaxe?

Para responder isso sem o chavão "depende", peguei um schema real de um sistema de logística brasileiro — com nomes de colunas em português, abreviações internas e relacionamentos N:N — e submeti a IA a um teste de estresse. O objetivo não foi pedir um "SELECT *", mas exigir agregações complexas que dependessem da compreensão profunda de como os dados se conectam. O que aconteceu quando o robô teve que lidar com a realidade de produção pode te surpreender.

Definindo o cenário de guerra: um schema SaaS nacional

Esqueça os exemplos clássicos de users e orders. Eu queria ver como o modelo lidava com algo closer ao mercado brasileiro. Usei a estrutura simplificada de um ERP de transporte rodoviário, contendo as tabelas tb_motoristas, tb_caminhoes, tb_viagens e uma tabela associativa tb_abastecimentos.

Aqui mora o primeiro obstáculo para qualquer automatização: a convenção de nomes. A coluna não é driver_id, é cod_motorista. A data não é created_at, é dt_hr_viagem. E há colunas que usam bit (0 ou 1) para status booleanos, um hábito antigo que ainda infesta muitos bancos PostgreSQL e SQL Server legados por aqui. O schema tinha cerca de 40 linhas de DDL (Data Definition Language) com chaves estrangeiras e índices compostos.

O teste inicial era simples: trazer o nome do motorista, a placa do caminhão e a quilometragem total rodada em viagens finalizadas no mês de abril de 2026. A IA acertou em cheio, identificando corretamente as tabelas tb_motoristas e tb_caminhoes e fazendo o JOIN através da tabela tb_viagens. Ela entendeu que status_viagem = 1 significava "concluído" baseando-se no comentário na coluna. Até aí, nada além do esperado para um modelo treinado em vastos repositórios de código.

A mágica acontece até a terceira tabela

O problema real apareci quando pedi dados que não moravam juntos. O pedido foi: "Liste todos os motoristas que não fizeram nenhuma viagem nos últimos 30 dias, mas que possuem um caminhão ativo". Isso exige um LEFT JOIN filtrado e a compreensão de que a ausência de registro na tabela de viagens é o dado que importa.

Aqui, o ChatGPT (versão 4o, usada no teste em 2026) tropeçou, mas não na sintaxe. Ele sugeriu um WHERE que eliminava os motoristas sem viagens, transformando o LEFT JOIN num INNER JOIN implícito — um erro clássico de quem está aprendendo SQL, mas que uma IA não deveria cometer. Ao apontar o erro ("Você está filtrando a tabela da direita no WHERE, isso cancela o LEFT"), ele corrigiu imediatamente, movendo a condição para a cláusula ON ou usando um IS NULL.

Isso prova que a ferramenta é um excelente "parceiro de ping-pong", mas perigosa como piloto automático. Ela entrega 90% do caminho, mas o último ajuste de performance ou lógica pura exige o olho humano. Se você estiver lidando com dados sensíveis, lembre-se que rodar modelos localmente, como o Llama 3, pode ser uma alternativa se a política de segurança da empresa proibir mandar o DDL do banco para a nuvem.

Onde o robô tropeça: alucinações de coluna

O ponto crítico do teste veio com uma solicitação de agregação financeira. Pedi para calcular o custo por quilômetro de cada viagem, cruzando dados de tb_viagens com uma suposta tabela de tb_custos_fixos. O erro? Eu não forneci a tabela tb_custos_fixos no DDL inicial.

O modelo não reclamou. Ele simplesmente inventou uma tabela com esse nome e criou colunas como vl_manutencao e vl_pedagio, gerando uma query que funcionaria sintaticamente em qualquer banco, mas que falharia na execução no meu schema específico.

Esse é o risco máximo para o júnior que quer "automatizar tudo". Se a IA assume que algo existe porque é statistically provável que exista em outros bancos, ela quebra a sua aplicação. Não é uma falha de inteligência, é uma característica de modelos preditivos: eles tentam completar o padrão. No contexto de banco de dados, assumir uma coluna pode significar um erro 500 na frente do cliente ou um relatório financeiro zerado sem explicação aparente. É um problema similar ao enfrentamos ao processar imagens de documentos fiscais, onde o modelo pode "ler" dados que não estão impressos no papel.

A solução? Force uma restrição no prompt: "Use APENAS as tabelas fornecidas acima. Se a informação não existir, retorne NULL ou avise, não invente tabelas". Com essa instrução, o comportamento mudou drasticamente. Ele passou a responder: "Não é possível calcular o custo de manutenção pois não há tabela de custos no schema fornecido". Honestidade em código é tão valiosa quanto a própria sintaxe.

Contexto é tudo: nomes não padronizados

Outro ponto de atrito foi o tratamento de nomenclatura brasileira. Em muitos bancos por aqui, usamos tp_situacao (Tipo de Situação) ou nr_cnpj. O ChatGPT lida bem com isso, mas confunde às vezes quando há ambiguidade.

Em um momento, ele sugeriu GROUP BY cod_motorista quando eu pedia o ranking de caminhões. Ele associou tb_caminhoes diretamente a tb_motoristas sem passar pela chave estrangeira correta em tb_viagens, pulando uma etapa lógica. Ele "achou" que motorista e caminhão eram a mesma entidade por causa da cardinalidade 1:1 comum em exemplos de treinamento.

Quando o schema foge do "padrão americano" ou convenções estritas como snake_case inglês, a margem de erro do modelo aumenta cerca de 20%, na minha estimativa. Ele funciona melhor se você fornecer não apenas o CREATE TABLE, mas também 2 ou 3 linhas de INSERT INTO com dados de exemplo. Ver dados reais ajuda o modelo a entender que cod_motorista 10 está ligado à placa ABC-1234, fixando o relacionamento na "cabeça" dele.

Otimizando o prompt para não jogar dinheiro fora

Descobri que a qualidade do SQL gerado tem uma correlação direta com a nitidez do DDL. Se você mandar um script gigantesco de 500 tabelas, a atenção do modelo se dispersa.

A estratégia vencedora foi o isolamento. Copiei apenas as tabelas estritamente necessárias para a pergunta (no máximo 4 ou 5 tabelas relacionadas) e colei no chat junto com a pergunta. Depois, pedi para "otimizar para performance". O ChatGPT sugeriu a criação de um índice na coluna dt_hr_viagem, o que fez sentido, pois eu estava filtrando por range de datas.

Ele errou ao sugerir um índice em uma coluna que já era chave primária (o que é redundante), mas acertou na sugestão de cobertura (covering index) para evitar o acesso à tabela de heap. Isso mostra que, para tuning de banco, ele serve como um segundo par de olhos, capaz de lembrar de conceitos como EXPLAIN ANALYZE quando você está focado apenas em trazer os dados.

Se você já usou ferramentas como o Copilot no Word para formatar textos, sabe que a IA é ótima para estrutura, mas carece de julgamento final. Com SQL é idêntico: ela formata a casa, mas não sabe qual mobília combina com a sua sala.

Veredito: Co-piloto, não piloto automático

Voltando à pergunta inicial: ele consegue escrever para o seu banco específico? Sim, mas com ressalvas severas. O ChatGPT de 2026 é capaz de entender schemas customizados e gerar JOINs complexos, contanto que você alimente ele com o contexto exato e limite a imaginação dele. A habilidade de escrever SQL não é mais o gargalo; o gargalo mudou para a capacidade de revisar e validar se a lógica de negócio da IA corresponde à realidade da sua empresa.

Nunca rode um UPDATE ou DELETE gerado por IA sem envolver uma transação (BEGIN TRANSACTION) e verificar o WHERE com lupa. O erro de sintaxe sumiu, mas o erro de lógica (atualizar a tabela errada ou usar a condição errada) ainda está muito presente, e esse custo de consertar dados corrompidos em produção é infinitamente maior do que o tempo de escrever a query na mão.

Use a ferramenta para quebrar a brancura da tela em branco, para descobrir funções de agregação que você esqueceu ou para formatar aquele CASE WHEN chato. Mas a responsabilidade de garantir que o número no relatório bate com o caixa da empresa continua sendo 100% sua.