O pg_infer é uma extensão para PostgreSQL 18+ que torna os componentes internos dos modelos transformer consultáveis em SQL. Isso permite que a inference do modelo seja precificada, paralelizada, combinada e filtrada como qualquer outra operação de banco de dados. Ele opera eficientemente em CPU, suporta modelos BitNet e pode descarregar a inference para réplicas ou hosts de recuperação de desastres.
A IA já é robusta o suficiente para lidar com grande parte da engenharia de dados, especialmente com fluxos de trabalho declarativos e fortes "quality gates". Para gerenciar o não determinismo dos LLMs, deve-se usar o “plan mode”, redefinições de contexto frequentes e testes externos. Formatos como o Substrait podem ser mais adequados que o SQL para agentes expressarem transformações, pois comunicam operações físicas. O papel de engenheiro de dados pode se integrar a uma função de "dados" mais ampla, à medida que a ergonomia dos agentes se torna mais relevante que a humana.
A Teads reduziu drasticamente em mais de 90% o uso de slots do BigQuery em seu serviço Audience Planning através de correções na aplicação e otimizações no modelo de dados. As correções incluíram coalescência de requisições com locks distribuídos Redis para eliminar queries duplicadas, validação fail-fast para filtros grandes e reescrita de grandes cláusulas IN como semi-joins. As otimizações de dados envolveram compressão de tipos de dados, pré-cálculo de trabalhos repetidos e uma estratégia de particionamento aprimorada, resultando na redução efetiva da pegada da tabela em aproximadamente 95%.
A IA empresarial enfrenta uma "pipeline tax": a movimentação de dados através de data warehouses, lakehouses, bancos de dados vector, camadas RAG e stacks de orquestração adiciona latência, desvio de governança e desafios de auditoria. Dados são copiados até quatro vezes, e respostas regulamentadas levam semanas para serem reconstruídas. A solução emergente é levar os agentes até os dados e tornar a governança nativa da camada de dados, com SQL databases, MCP e Iceberg como peças centrais. Essa mesma mudança está redefinindo a migração como uma capacidade contínua orientada por IA, em vez de um projeto pontual.
O logging de contexto baseado em grafos está emergindo como a camada de proveniência que faltava para os fluxos de trabalho de RAG e sistemas baseados em agentes.
Ao consultar eventos estruturados de observability e rastrear métricas chave no nível do span, como consumo de token, duração/latency e taxas de erro (planejamento, chamadas de ferramentas e geração de resposta), as equipes podem monitorar eficazmente os agentes em produção para detectar problemas como inchaço de contexto em conversas multi-turno, picos de token, chamadas de ferramentas lentas ou mudanças na complexidade das perguntas.
A IA é genuinamente capacitadora para a ciência de dados, tornando a programação, tradução, entrada de voz e o aprendizado mais acessíveis. No entanto, ela também é prejudicial devido ao custo ambiental, questões de direitos autorais, concentração de riqueza, pensamento superficial e acesso desigual. Essa tensão não pode ser resolvida de forma simples, mas líderes de ciência de dados ainda precisam se engajar seriamente com a IA para ajudar as pessoas a usá-la bem.
O Conselho de IA mostrou que a divisão entre dados e IA está diminuindo, com a maioria dos fornecedores se posicionando como camadas de infraestrutura de IA para retrieval de contexto, orquestração ou inference. Novos sistemas, como o LanceDB, estão sendo construídos nativamente para workloads de LLM e multimodais. A avaliação de desempenho também está mudando: testes com dbt Semantic Layer, ADE-bench e simulações de 90 dias indicam que agentes operam melhor em tarefas bem especificadas e com contexto rico. Eles melhoram ainda mais quando há acesso a contexto cross-system e stateful de plataformas como GitHub, Slack, Notion e dbt. A próxima barreira significativa é a eficiência de token e compute.
O mondayDB 3 é um sistema HTAP projetado para gerenciar mais de um trilhão de tabelas dinâmicas, em constante evolução e com schemas altamente flexíveis. A solução substituiu a arquitetura anterior baseada em MySQL + JSON por uma arquitetura Lambda baseada em CQRS, impulsionada por DuckDB. Essa nova abordagem utiliza snapshots imutáveis em object storage, um WAL externo para alterações em tempo real, e uma camada de serviço soft-stateful que sincroniza e consulta arquivos DuckDB locais a cada leitura.
Artigo da Spotify Engineering propõe tratar as avaliações de LLM (LLM evals) e experimentos A/B online como um funil. A ideia é usar LLM judges (avaliadores baseados em LLM) no início do processo para verificar a qualidade (relevância, tom e coerência) e filtrar ideias fracas antes que consumam recursos de experimentos. Essa abordagem visa aumentar a taxa de sucesso dos experimentos. A execução de evals sobre os resultados dos experimentos cria um ciclo de feedback que calibra e aprimora continuamente os próprios LLM judges.
As capacidades de longo prazo dos agentes de codificação serão mais determinadas pela qualidade dos ciclos de feedback do que pela inteligência bruta do modelo. Tarefas com feedback rápido, preciso e automatizado (como a construção de bancos de dados de alta performance com especificações formais) se tornarão surpreendentemente “fáceis” para os agentes, enquanto tarefas que dependem de feedback humano lento e subjetivo permanecerão relativamente “difíceis”.
Object storage pode suportar OLTP serializável se construído com três primitivos de escrita (PUTs atômicos, PUT If-Match/If-None-Match condicionais e LISTs fortemente consistentes) e três primitivos de leitura (GETs atômicos, GET If-None-Match condicional e listagem consistente). A principal troca é entre safety e o custo de contenção, sendo necessária uma coleta de lixo segura para evitar o crescimento indefinido do armazenamento.
A Netflix substituiu seu motor de movimentação de dados Cassandra para Iceberg por uma plataforma em camadas que lê backups diretamente do S3, os converte em Spark DataFrames e permite que cada abstração de dados construa seu próprio conector otimizado. O motor movimenta aproximadamente 3 PB/dia, e a migração utiliza shadow validation, observability aprimorada e um fallback Maestro Decider para a solução anterior. Isso possibilitou uma transição transparente sem alterações no código downstream.
Agentes de IA capazes de escrever em sistemas de produção criam um novo problema de responsabilidade e recuperação. Um agente da Replit, por exemplo, já apagou um banco de dados em produção, e o problema principal não foi a falha em si, mas a ausência de propriedade clara, guardrails e um plano de rollback. Com 86% dos líderes de TI e segurança esperando que os agentes de IA superem os controles atuais, a governança torna-se uma responsabilidade compartilhada entre arquitetura, segurança, jurídico e negócio. Controles práticos como limites de políticas, observability, triagem com intervenção humana (human-in-the-loop) e mecanismos explícitos de recuperação são essenciais para evitar que ferramentas autônomas se tornem um risco para toda a empresa.
O MemKV da MinIO é um armazenamento de contexto de memória em escala de petabytes para inference de IA, projetado para preservar e compartilhar o estado da sessão entre clusters de GPU. Ao mover o contexto diretamente de NVMe para o caminho de dados da IA via 800 GbE RDMA, ele aborda o problema do "recompute tax" e afirma alcançar mais de 95% de melhor utilização de GPU e cerca de 50% menos custo por token em cargas de trabalho de benchmark.
O PostgreSQL apresenta inconsistências na forma como resolve nomes de colunas e expressões em cláusulas ORDER BY. Por exemplo, identificadores simples (como ORDER BY a) procuram primeiramente por aliases na lista SELECT, enquanto qualquer expressão (como ORDER BY -a) se resolve contra a cláusula FROM. Isso leva a comportamentos confusos quando se utilizam aliases, aspas, GROUP BY, funções de janela e UNION.
A ingestão de dados parece simples, mas uma escolha inadequada pode gerar custos ocultos através de conectores falhos, schema drift, over-engineering e tempo de engenharia desperdiçado. A abordagem ideal geralmente é híbrida: conectores gerenciados para SaaS padrão, streaming apenas quando baixa latência é crucial, e pipelines customizados para fontes de dados de nicho ou legadas.
Uma grande pane na AWS US-EAST-1 em maio foi causada por um evento de superaquecimento em um único data center, resultando em interrupções de várias horas para serviços de alto perfil como a Coinbase. O incidente destacou a diferença crítica entre alta disponibilidade Multi-AZ (que falhou em proteger cargas de trabalho sensíveis à latência) e a verdadeira recuperação de desastres cross-region.
A transição da Cloudflare para retenção por tenant em uma tabela massiva do ClickHouse, "Ready-Analytics", revelou um limite inesperado de escalabilidade: o planejamento de queries, e não o I/O ou volume de varredura, tornou-se o gargalo à medida que as 'parts per replica' aumentavam. O tracing mostrou que 45% do tempo de CPU da query folha era gasto na filtragem de partes. A mudança para um shared lock e, subsequentemente, para um cache de leitura compartilhada, removeu a maior parte da contenção e reduziu drasticamente a latência das queries.
Agentes de software interagem com sistemas de maneira distinta dos humanos, o que exige uma reestruturação da infraestrutura. É necessário repensar o design para incluir snapshots, branching, escalabilidade elástica, alta concorrência, isolamento e experimentação de baixo custo.
