Data 360 da Salesforce processa 1 quatrilhão de registros/mês com arquitetura flexível, mas metadados viraram gargalo

O Data 360 da Salesforce não é só um CDP: é uma infraestrutura de dados em tempo real projetada para escalar com o caos, e o caos aqui é estruturado. Ele lida com 1 quatrilhão de registros/mês não apesar da variabilidade, mas *porque* foi construído para absorvê-la: schemas customizados, grafos de relacionamento dinâmicos, múltiplos back-ends (Snowflake, BigQuery, Databricks, Fabric) via Zero Copy File Federation, e até 6.000 tabelas por ambiente. O que torna isso viável é a interpretação em tempo de execução dos metadados do cliente, não um schema fixo, mas um motor que lê, valida e recompõe relações na hora do job Spark. Mas essa flexibilidade tem um preço: os metadados viraram o novo bottleneck. Um payload de 500 MB não é só um problema de UI lenta; é um sintoma de que o sistema está tentando carregar, serializar e explorar bilhões de planos de consulta candidatos antes mesmo de executar uma única linha de código.

Isso coloca o Data 360 no mesmo time de sistemas como mondayDB 3 (trilhões de tabelas) e o monitoramento da Databricks (10 trilhões de amostras/dia): todos enfrentam o colapso da camada de metadados quando a escala ultrapassa o limite de ‘gestão humana’. A resposta da Salesforce, planejamento de consulta em fases, é pragmática, mas revela um tradeoff crítico: otimização local em vez de global. Não é um bug, é uma escolha arquitetural explícita para manter SLA em ambientes onde cada cliente define seu próprio universo de dados.

A cobertura anterior de 17 de junho já destacava a arquitetura adaptativa do Data 360, mas tratava metadados como um desafio operacional secundário. Agora, em 18 de junho, a Salesforce confirma que a gestão de metadados deixou de ser um ponto de atenção e se tornou a *principal restrição arquitetural*, com impacto direto em query planning, workload execution e usabilidade. Isso reflete uma evolução real: o sistema passou da fase de ‘escalar os dados’ para a fase de ‘escalar a compreensão dos dados’. Também houve mudança conceitual: o antigo ‘Data Cloud’ foi renomeado oficialmente para ‘Data 360’ na Dreamforce 2025, e sua integração com Agentforce (agentes de IA) deixou de ser promessa para ser exigência funcional, o que eleva ainda mais o custo da lentidão no plano de consulta.

Para engenheiros de dados, isso não é só sobre performance: é sobre governança em escala. Se o plano de consulta leva minutos para ser gerado, você não consegue auditar, testar ou versionar alterações de modelo com segurança. Se os metadados são carregados em blocos de 500 MB, ferramentas de CI/CD como CLI ou Change Sets ficam limitadas, e equipes recorrem a scripts personalizados ou soluções de terceiros (Elements.cloud, CapStorm, Metadata GPT). Para quem constrói pipelines com Zero Copy, o gargalo de metadados afeta diretamente o custo: um plano ruim gera mais leituras externas, mais créditos consumidos, e menos eficiência no uso de recursos. Em resumo: a próxima fronteira do data engineering não é processar mais dados, mas fazer com que o sistema entenda melhor o que ele já sabe.