MOR não é otimização de armazenamento, é uma mudança arquitetural

O Merge-on-Read (MoR) não é uma otimização de I/O ou compressão, é uma mudança de contrato entre escrita e leitura. Enquanto o Copy-on-Write reescreve blocos inteiros de dados para garantir que cada leitura seja servida de um único arquivo Parquet, o MoR assume que a consistência lógica pode ser construída em tempo real, mesclando camadas base e delta no momento da consulta. Isso exige um runtime capaz de resolver conflitos de versão, aplicar exclusões posicionais ou por igualdade e gerenciar a visibilidade transacional sem bloqueio. A compactação não é um 'mantimento opcional': é o mecanismo que converte custo de leitura em custo de processamento controlado, e sua falha gera amplificação de leitura exponencial, não só mais arquivos lidos, mas mais deslocamentos de memória, mais buscas em disco e pior uso de cache.

Plataformas como Delta Lake (desde v2.3), Iceberg v2 no Snowflake (a partir do bundle 2026_03) e Hudi já adotam MoR com variações técnicas concretas: Iceberg usa arquivos de exclusão posicionais por padrão agora, Delta Lake depende de Deletion Vectors desde 2023, e Hudi mantém logs delta com esquema de versionamento próprio. O que une essas implementações não é a sintaxe SQL, mas o modelo de execução: leituras são pipelines de fusão, não acessos diretos.

A cobertura anterior do CEVIU sobre Bintrail (2026-05-25) já mostrava como binlogs indexados permitem time-travel no MySQL sem cópias de dados, um princípio semelhante ao MoR, mas limitado ao nível de log de transação. Agora, com o bundle 2026_03 do Snowflake e a adoção generalizada de Deletion Vectors na Databricks, o MoR deixou de ser um modo experimental em data lakehouses para virar o comportamento padrão em operações UPDATE, DELETE e MERGE em tabelas Iceberg v2. Não é mais 'suporte a MoR': é a nova camada de abstração de atualização em ambientes de produção.

Para engenheiros de dados, isso muda o perfil de performance esperado: latência de escrita cai, mas a previsibilidade de leitura exige monitoramento ativo de métricas como 'delta file count per partition' e 'read amplification ratio'. Para equipes de analytics, queries que antes rodavam em 2 segundos podem passar para 8 segundos se a compactação estagnar, e esse gargalo não aparece no explain plan, só no tempo real. A governança também se transforma: políticas de retention precisam considerar tanto arquivos base quanto delta, e ferramentas de lineage devem rastrear não apenas origens, mas também quais logs delta contribuíram para um resultado específico.