Esta semana em cloud (28/set–04/out): o dado parou de viajar — agora a consulta vai até ele

TL;DR — A AWS embutiu o DuckDB no Aurora PostgreSQL para consultar tabelas Iceberg e arquivos Parquet no S3 sem ETL reverso, e levou o S3 Tables ao Iceberg V3 completo, com deletion vectors e row lineage. O Google colocou o Spanner Omni em GA para rodar em data center próprio ou em outra nuvem. O recado da semana: o formato aberto virou o contrato entre os motores, e cada pipeline que só copia dado passou a ser custo questionável.

A semana passada foi sobre quem pode publicar no pipeline. Esta foi sobre o que o pipeline de dados ainda precisa carregar — e a resposta dos provedores foi: menos do que você imagina.

Não houve um anúncio único que mudasse o mercado. Houve uma sequência de lançamentos, de provedores diferentes, apontando para a mesma direção: o dado fica onde está, em formato aberto, e o motor vai até ele. A AWS colocou um motor analítico dentro do Aurora PostgreSQL para ler o data lake sem cópia. O S3 Tables passou a falar o Iceberg V3 inteiro. O S3 Vectors aprendeu a filtrar antes de buscar. E o Google tirou o Spanner do Google Cloud com a disponibilidade geral do Spanner Omni.

Quem mantém um pipeline de reverse ETL rodando de madrugada conhece o desconforto: boa parte dele existe só para mover o mesmo dado de um formato para outro.

Por que o reverse ETL ficou difícil de justificar?

Porque o motor transacional passou a ler o formato do lake.

A nova capacidade do Aurora PostgreSQL (versões 17.11+ e 18.6+) embute o DuckDB no banco: você habilita a extensão aurora_analytics, associa uma IAM role com acesso ao S3 e ao Glue Data Catalog e cria foreign tables apontando para tabelas Iceberg ou arquivos Parquet — com o schema inferido dos metadados. A partir daí, uma única query SQL faz JOIN ou UNION entre a tabela operacional e cinco anos de histórico no S3. Catálogos externos compatíveis com o Iceberg REST Catalog entram pela federação do Glue. Não há taxa adicional: paga-se o compute da consulta e as requisições ao S3.

O exemplo da própria AWS é didático: transações dos últimos sete dias no Aurora, histórico em Parquet no bucket, e uma consulta só para os dois. Antes, isso exigia um job copiando o histórico de volta para o banco — ou um warehouse no meio.

Há limites honestos. Para latência de milissegundos, a recomendação é materializar o dado do lake numa tabela nativa (CREATE TABLE AS SELECT ou MERGE INTO), e a consulta analítica deve ir para uma réplica para não disputar recurso com a aplicação. Mas o desenho muda de "copiar tudo, sempre" para "ler no lugar, materializar só o quente".

O que o Iceberg V3 resolve na prática?

Dois custos que todo time de dados conhece e raramente mede: exclusão pontual e JSON em coluna de texto.

O S3 Tables passou a suportar todos os tipos do Iceberg V3. Os destaques:

Deletion vectors substituem os arquivos de delete posicionais do V2. No exemplo da AWS, excluir 50 mil registros de uma tabela de 2 bilhões de linhas deixa de gerar milhares de pequenos arquivos que lentificam as consultas até a compactação — vira um único vetor binário.
Row lineage adiciona identificador de linha e número de sequência da última alteração a cada registro, para que pipelines downstream encontrem o que mudou sem varrer a tabela.
Novos tipos nativos: variant para dado semiestruturado em formato colunar (com estatísticas que permitem poda de arquivos), timestamps em nanossegundos, geometry e geography.

O upgrade de uma tabela V2 é um ALTER TABLE ... SET TBLPROPERTIES ('format-version' = '3'), sem reescrever dados, e leitores V2 continuam funcionando até você usar recursos exclusivos do V3. O ponto que importa fora da AWS: o V3 é especificação aberta. O Google já tinha colocado em preview, em junho, tabelas V3 com deletion vectors no catálogo do seu Lakehouse — o recurso é do formato, não do provedor.

Para o leitor brasileiro, o deletion vector tem um nome familiar: pedido de exclusão de titular da LGPD. Apagar o registro de um cliente numa tabela de bilhões de linhas era exatamente o tipo de operação que punia a performance do lake até a próxima compactação.

Lançamento da semana	O que elimina	Formato/padrão por baixo	Custo extra
Aurora PostgreSQL + Iceberg/Parquet	Reverse ETL do lake para o banco	Apache Iceberg, Parquet, Iceberg REST Catalog	Não (compute + requisições S3)
S3 Tables com Iceberg V3	Arquivos de delete posicionais, JSON em texto	Apache Iceberg V3	Não informado à parte
S3 Vectors com pre-filtering	Recall baixo em busca filtrada por tenant	Metadados por vetor (até 2 KB)	Não
Spanner Omni GA	Dependência de rodar o banco no Google Cloud	Spanner (proprietário) em VM ou Kubernetes	Licença anual por vCPU

O que muda quando o banco roda em qualquer lugar?

O Spanner Omni chegou a GA como a versão autogerenciada do Spanner, para rodar em VMs ou Kubernetes no data center próprio, em outra nuvem ou no laptop do desenvolvedor. Segundo o Google, passou de 2 milhões de downloads desde o anúncio. A GA traz TLS, autenticação, audit logging, backup e restore, e worker nodes stateless para tirar operações pesadas dos servidores primários. A Developer Edition é gratuita para ambientes não produtivos (licença de 90 dias, sem expiração num servidor de até 4 vCPUs); a Commercial Edition é assinatura anual por vCPU.

As letras miúdas valem a leitura: não há SLA do Google quando o banco roda na sua infraestrutura, a operação do dia a dia é sua e as integrações nativas com BigQuery, Knowledge Catalog e Gemini Enterprise ficam de fora. Na mesma semana, o Spanner gerenciado ganhou o Spanner Queues em GA — mensageria transacional dentro do banco, em que enfileirar uma mensagem é mais uma escrita na mesma transação, dispensando o padrão outbox.

A leitura que fazemos: portabilidade de infraestrutura é diferente de portabilidade de software. O Omni resolve residência de dado e operação híbrida para quem já está no Spanner; não transforma um produto proprietário em padrão aberto. É a mesma distinção que guia o desenho de Kubernetes on-premises sem lock-in: rodar em qualquer lugar só vale se você também puder sair.

Quantos pipelines da sua empresa existem só para copiar dado? A Nuvem Online mapeia o fluxo de dados e corta o que o formato aberto já resolve.

O que isso significa para quem opera infra no Brasil?

Três consequências práticas, em ordem de urgência.

1. Inventarie os pipelines que só copiam. Liste os jobs de ETL e reverse ETL e marque os que não transformam nada — só levam o dado de um lugar para outro para que outro motor consiga ler. Cada um deles carrega armazenamento duplicado, transferência entre zonas ou nuvens e horas de engenharia de manutenção. Com motores lendo Iceberg e Parquet no lugar, parte dessa lista pode simplesmente ser desligada.

2. Padronize no formato, não no motor. O fio da semana é que Iceberg e Parquet viraram a interface comum entre banco transacional, warehouse, motor de busca vetorial e agente. Guardar o dado histórico nesses formatos, num object storage com catálogo aberto, preserva a liberdade de trocar o motor depois — inclusive para alternativas de comunidade como DuckDB, Trino ou Spark rodando no seu próprio cluster. O caso do PayPal publicado na semana reforça o mesmo ponto pelo lado do processamento: a migração de um Hadoop fragmentado para Spark gerenciado melhorou em 25% o tempo das cargas principais e em 30% a aderência ao SLA, porque padronizou o motor sobre um storage comum.

3. Integridade e escopo antes de escala. Dois lançamentos discretos merecem atenção de quem move muito dado. Os SDKs do Cloud Storage passaram a calcular e enviar checksums por padrão no upload e a verificá-los no download — atualizar as bibliotecas fecha uma janela de corrupção silenciosa que existia quando a aplicação não informava o checksum. E o S3 Vectors ganhou pre-filtering por metadados: em índices no modo ENHANCED, o filtro (tenant, categoria, data) é resolvido antes da busca por similaridade, com até 5x mais resultados corretos em filtros seletivos. Índices existentes continuam no modo CLASSIC até serem atualizados — quem faz RAG multi-tenant deveria fazer isso esta semana.

O que mais aconteceu na semana

Fora do fio dos dados, quatro movimentos merecem nota:

Startup de pod sem pagar CPU ociosa. O GKE colocou em preview (1.36+) o CPU startup boost: o VPA aumenta a CPU do container durante a inicialização e devolve ao baseline depois do readiness probe, sem reiniciar o pod, com até 2x de ganho no tempo de startup de aplicações Java, Node.js e Python. Por baixo está o In-place Pod Resize, GA no Kubernetes 1.35 — o que significa que a mesma ideia é implementável fora do GKE. Para o desenho de escala por sinal em vez de por CPU, veja nosso guia de autoscaling com KEDA e HPA.
Sobreposição de IP resolvida no gateway. A Oracle lançou o NAT no DRG: tradução 1:1 de IPv4, bidirecional e com prioridade determinística, aplicada direto nos attachments de VCN, FastConnect, VPN e peering entre regiões, sem appliance e sem custo extra. Para fusões, integrações com parceiros e DR entre regiões com CIDRs conflitantes, é uma renumeração a menos.
Detecção de incidentes em streaming. A CNCF publicou o relato da Atlassian reconstruindo a detecção de incidentes sobre OpenTelemetry, Apache Kafka e Apache Flink no Kubernetes: latência caindo de 40 para menos de 10 segundos e corte de 97% no custo operacional, segundo o relato — um caso de stack inteiramente de comunidade.
Agentes ganharam acesso controlado à nuvem. O Google colocou em preview um servidor MCP remoto do Google Cloud CLI e levou a GA o Data Agent Kit, que dá a agentes de código contexto sobre dados e pipelines; a AWS abriu em preview o Well-Architected Agent, que analisa a arquitetura da conta e sugere correções. O padrão se repete: o agente passa a operar com as permissões de alguém — e precisa de escopo tão restrito quanto o de qualquer identidade de serviço.

Perguntas Frequentes

Consultar o data lake direto do banco transacional não vai derrubar a performance da aplicação?
Pode, se a consulta analítica rodar na mesma instância que atende o tráfego da aplicação. No caso do Aurora, as leituras podem ir para réplicas do cluster, e o motor aplica predicate pushdown, column pruning e cache local para ler só o necessário. A regra prática é separar: consulta exploratória e de agente vai para réplica; dado que precisa responder em milissegundos é materializado em tabela nativa. O ganho real é eliminar o pipeline de cópia, não transformar o banco de produção em warehouse.

Vale migrar minhas tabelas Iceberg V2 para V3 agora?
Se você sofre com exclusões pontuais frequentes (pedidos de titular da LGPD, correções de registro) ou guarda JSON em colunas de texto, sim — deletion vectors e o tipo variant atacam exatamente esses dois custos. O upgrade é uma alteração de propriedade da tabela, sem reescrever dados, mas antes confirme que todos os motores que leem a tabela entendem V3. No S3 Tables, leitores V2 continuam funcionando até você adotar recursos exclusivos do V3; em outros catálogos e motores, verifique a versão suportada um por um.

O Spanner Omni elimina o lock-in com o Google?
Reduz o lock-in de infraestrutura, não o de software. Você passa a rodar o mesmo banco em VMs ou Kubernetes no seu data center ou em outra nuvem, mas continua dependente de um produto proprietário com licença anual por vCPU, sem SLA do fornecedor quando autogerenciado e sem as integrações nativas com BigQuery e Gemini Enterprise. É uma boa saída para quem já está no Spanner e precisa de residência de dados; para projeto novo, compare com bancos distribuídos de licença aberta antes de decidir.

Onde a cópia de dados mais pesa no custo de uma empresa brasileira?
Em três lugares: armazenamento duplicado (o mesmo dado no banco, no lake e no warehouse), transferência entre zonas, regiões ou nuvens, e as horas de engenharia para manter pipelines de ETL e reverse ETL funcionando. O terceiro costuma ser o maior e o menos medido. Antes de criar um novo pipeline de cópia, vale perguntar se o consumidor não consegue ler o formato aberto onde o dado já está.

Fontes: