A Ascensão dos Multi-Query Engines

O que antes era um problema de custo marginal em data warehouses virou uma crise operacional com a escalada dos agentes de IA: consultas pequenas, intermitentes e altamente concorrentes sobrecarregam engines monolíticas. O QueryFlux, lançado em 4 de junho, não é só mais um proxy SQL, ele é um 'motor de decisão' em tempo real, traduzindo dialetos com sqlglot, roteando por Iceberg (não por cópias ou ETLs), e escolhendo entre DuckDB (US$0,01/query), Trino (baixa latência em lakehouses) ou Snowflake (alta concorrência estruturada). A chave técnica está na camada aberta: Iceberg garante consistência transacional entre engines, eliminando o trade-off entre performance e portabilidade. Isso permite que equipes mantenham seus pipelines atuais enquanto deslocam cargas específicas, como joins rápidos em memória ou agregações pesadas em cluster, sem refatoração.

O cenário se conecta diretamente à tendência de 'inferência distribuída': assim como o Inference Router da DigitalOcean (6 de junho) direciona requisições de texto para modelos leves e imagens para multimodais, o QueryFlux faz o mesmo com dados, mas com base em métricas observáveis (tempo de execução histórico, custo por GB processado, taxa de falha) e não em regras estáticas. Empresas como LakeOps já reportam redução de 56% nos custos de consulta ao substituir rotas fixas por decisões dinâmicas alimentadas por logs de execução anteriores.

Em 27 de maio, a CEVIU destacou o outsourcing + IA local como resposta aos custos crescentes de APIs frontier. Agora, em 4 de junho, o foco mudou do nível de modelo para o nível de dado: não basta trocar o fornecedor de LLM, é preciso redesenhar como cada byte é processado. O QueryFlux não é um rumor ou conceito, é código aberto em Rust, com suporte nativo a StarRocks e Flink (não citados na cobertura anterior), e já integrado a stacks que usam Substrait (mencionado em 25 de maio como caminho para SQL declarativo). Antes falávamos em 'automatizar engenharia de dados'; agora, a automação opera no nível de roteamento de cada query, com IA embutida para prever risco de timeout ou overprovisioning antes da execução.

Porque o custo de inferência de IA não é só de tokens, é também de dados. Um agente que gera 12 consultas por segundo pode gastar mais com o data warehouse do que com o LLM. A Gartner já alerta que 40% dos projetos de IA agentiva falharão até 2027 por esse motivo. A solução não está em escalar o warehouse, mas em fragmentar a carga: DuckDB para dashboards interativos, Athena para ad-hoc baratos, Spark para ETLs pesados, tudo sobre os mesmos dados Iceberg. Isso muda o papel do engenheiro de dados: de construtor de pipelines para curador de políticas de roteamento, definindo tetos de custo por workload e metas de latência por tipo de consulta. Não é menos engenharia, é engenharia com outro vetor de otimização.