O custo real de colocar um modelo de 4B para planejar consultas no PostgreSQL

A ideia de colocar redes neurais para escolher o plano de execução de bancos relacionais reapareceu com força nas últimas semanas. O gatilho foi a publicação recente sobre o treinamento de um modelo de linguagem de 4 bilhões de parâmetros que teria gerado planos 81% mais rápidos que o otimizador padrão do PostgreSQL. O experimento consumiu perto de 800 dólares alugando dois aceleradores H100 por cerca de 95 horas, além de algumas centenas de dólares em APIs proprietárias para coletar trajetórias de treino.

A reação da comunidade se dividiu de imediato. De um lado, leitores deslumbrados com o percentual de aceleração decretaram que a heurística clássica de bancos relacionais está com os dias contados. Do outro, veteranos de infraestrutura apontaram que o benchmark rodou sobre uma base de 8 GB totalmente carregada na memória, com consultas somente leitura já aquecidas, e concluíram que tudo não passa de pirotecnia acadêmica sem aplicação prática. Houve até quem resumisse a conversa dizendo que basta criar os índices corretos.

Eu discordo das duas pontas. Resumir o problema a criar índices ignora que otimização de consultas com múltiplos joins é um problema NP-difícil, no qual o próprio PostgreSQL apela desde 2001 para algoritmos genéticos com o GEQO quando o número de tabelas passa do limite configurado. Por outro lado, achar que um modelo de 4B vai assumir o papel do planejador em um ambiente de produção revela um desconhecimento profundo sobre a matemática de latência em sistemas transacionais.

Na minha rotina administrando instâncias de PostgreSQL em servidores dedicados e VPS, a métrica que dita a vida da aplicação é o tempo total de resposta no relógio de parede. O planejador nativo do Postgres, escrito em C e refinado ao longo de três décadas, costuma tomar decisões em frações de milissegundo. Em consultas transacionais rotineiras, o custo de planejar gira frequentemente em torno de 0,1 a 0,5 milissegundo.

Se você substitui esse mecanismo por um modelo de 4 bilhões de parâmetros, a física da inferência entra na conta. Mesmo usando quantização agressiva em 4 bits e executando em hardware especializado, a passagem direta por uma rede desse porte para processar a árvore sintática da consulta e o estado das tabelas vai exigir dezenas de milissegundos. Se a inferência levar 20 milissegundos para encontrar um plano que faz a busca cair de 5 milissegundos para 1 milissegundo, a operação final ficou quatro vezes mais lenta para o usuário que aguarda a resposta.

Esse balanço só fecha quando a consulta original já é catastrófica. Se estamos falando de uma extração analítica que roda por quarenta minutos cruzando dezenas de tabelas de faturamento, gastar meio segundo consultando um modelo externo para economizar dez minutos é um excelente negócio. O problema é que quase ninguém desenha sistemas separando essas fronteiras com a clareza necessária antes de cogitar trocar o miolo do banco de dados.

Outro ponto que os defensores da substituição ignoram é a perda de previsibilidade. Otimizadores tradicionais são imperfeitos, mas operam sobre regras determinísticas e estatísticas coletadas pelo processo de análise periódica do banco. Quando uma consulta degrada no Postgres, você roda um comando de inspeção e descobre exatamente onde a estimativa de linhas divergiu da realidade, ajustando o custo de páginas randômicas, aumentando o alvo de estatísticas da coluna ou forçando o uso de um índice específico.

Com um modelo de linguagem decidindo junções de tabelas, o comportamento passa a depender da distribuição probabilística dos pesos. Se a aplicação alterar um parâmetro de busca ou renomear um identificador na consulta gerada pelo framework, o modelo pode simplesmente alucinar uma estratégia diferente e ignorar um índice perfeito. Em um incidente de banco travado às três da manhã, a última coisa que um time de operações precisa é tentar adivinhar por que uma rede neural decidiu fazer uma varredura sequencial em uma tabela com cinquenta milhões de registros.

Há também a questão do custo de infraestrutura contínua. Manter servidores com placas gráficas de ponta disponíveis apenas para atender chamadas de planejamento de consultas adiciona milhares de dólares por mês à fatura de hospedagem. Para a maioria das empresas que operam sistemas de gestão e comércio eletrônico em servidores próprios sem aceleradores dedicados, essa arquitetura é financeiramente inviável. O ganho marginal de processamento no banco é engolido pelo custo das máquinas auxiliares de inferência.

Existe, contudo, um espaço real onde modelos compactos podem ajudar na camada de banco de dados, mas ele não fica dentro do laço fechado de execução de cada requisição. O papel viável para aprendizado de máquina nessa área é consultivo e assíncrono.

Imagine uma rotina em segundo plano que analisa o log de consultas lentas capturadas pela extensão de estatísticas do banco durante a semana. Fora do caminho crítico dos usuários, esse componente pode gastar o tempo que for necessário testando permutações de planos, identificando correlações estatísticas entre colunas que o planejador padrão não enxergou e sugerindo índices compostos ou reescritas de consultas complexas para o time de desenvolvimento. Nesse modelo de trabalho, a latência de inferência deixa de importar, porque o resultado final é transformado em comandos estruturados comuns aplicados diretamente no catálogo do Postgres.

Trocar a heurística interna do banco por um modelo generativo em tempo real resolve uma dor que poucos têm enquanto cria problemas de latência e custo que quase ninguém consegue sustentar. Enquanto a inferência não rodar na escala de microssegundos em processadores genéricos sem consumo abusivo de energia, o planejador clássico em C continuará sendo a única escolha razoável para o tráfego que sustenta o negócio.

Fontes

• https://rohanbansal.com/qorl