Aurora PostgreSQL lê o data lake: Iceberg e Parquet direto, sem ETL

Quantos pipelines do seu time existem só para levar o dado do data lake até um lugar onde o banco de dados consegue lê-lo? Em muitas empresas, a resposta é "mais do que gostaríamos". Em 30 de setembro de 2026, a AWS anunciou que o Amazon Aurora PostgreSQL passou a consultar dados em Apache Iceberg e Parquet diretamente no data lake, sem precisar copiá-los antes. Neste artigo explicamos o que foi lançado, como funciona por dentro, onde faz sentido usar e o que continua sendo trabalho do time de dados.

O problema que o recurso resolve

Aplicações costumam combinar dois tipos de dado: o operacional, recente e transacional, que vive no banco, e o histórico, volumoso, que vive em arquivos no S3. Até aqui, juntar os dois quase sempre exigia um pipeline que movia parte do data lake para dentro do banco, ou o caminho inverso. Como lembrou a Techzine ao noticiar o lançamento, isso consome armazenamento e compute extras e obriga o time a manter várias cópias sincronizadas do mesmo dado.

A proposta do novo recurso é eliminar essa etapa de cópia para os casos em que a consulta pode ir até o dado, em vez de o dado vir até a consulta.

Como funciona

Segundo o AWS News Blog e a documentação do Aurora, o recurso tem três peças:

1. Motor analítico dentro do banco. O DuckDB roda embutido no Aurora PostgreSQL, no mesmo processo do servidor, e é ativado pela extensão aurora_analytics. O PostgreSQL planeja a consulta e entrega a execução analítica ao DuckDB, sem saltos extras de rede.
2. Tabelas externas que apontam para o lake. Você cria foreign tables que guardam só os metadados (esquema e localização). O comando IMPORT FOREIGN SCHEMA cria de uma vez as tabelas de todo um banco do Glue Data Catalog, inferindo os esquemas.
3. O SQL de sempre. A mesma consulta pode juntar a tabela operacional com o histórico que está no S3. Para drivers, ORMs e ferramentas de BI, a tabela externa se comporta como uma tabela comum.

Onde ele se conecta

• Tabelas Iceberg no AWS Glue Data Catalog;
• Dados Parquet e Iceberg no Amazon S3 e no S3 Tables;
• Catálogos compatíveis com Iceberg REST, por meio da federação do Glue Data Catalog.

Os três usos que a AWS destaca

Dashboards em tempo real com dado atual e histórico

Um painel que mostra as vendas de hoje ao lado da média dos últimos dois anos pode consultar as duas fontes numa única query, sem esperar o próximo ciclo de ETL.

Transações enriquecidas com contexto

Uma transação nova pode ser avaliada à luz do histórico do cliente que está no lake, por exemplo para regras de risco ou de recomendação.

Agentes de IA que raciocinam sobre os dois mundos

Agentes nem sempre sabem de antemão de qual dado vão precisar, o que torna difícil copiar tudo antecipadamente. Poder consultar o histórico sob demanda, pelo mesmo banco, simplifica a arquitetura.

O que continua nas mãos do time

O recurso tira um pipeline do caminho, mas não tira a engenharia. O ganho de desempenho e de custo depende de decisões que continuam sendo do time:

• Modelagem e organização dos arquivos. O motor usa as estatísticas do Parquet e do Iceberg para pular arquivos e grupos de linhas (predicate pushdown) e lê só as colunas necessárias. Dado bem organizado pelas colunas mais filtradas permite pular mais; dado mal organizado obriga a ler mais do S3.
• Custo por consulta. Cada leitura no S3 é cobrada. A função aurora_analytics_stat_statements() mostra linhas lidas, bytes lidos do S3 e acertos de cache por consulta, e o CloudWatch traz as métricas por instância.
• Memória. As consultas respeitam o orçamento definido em aurora_analytics.query_mem; quando ele estoura, o processamento transborda para o disco local e fica mais lento.
• O que materializar. O dado mais quente pode ser copiado para uma tabela nativa com CREATE TABLE AS SELECT, INSERT INTO ... SELECT ou MERGE INTO, para latência de milissegundos de um dígito. Essas escritas precisam rodar na instância writer.
• Onde rodar. Consultas de leitura podem ir para réplicas de leitura, tirando a varredura analítica da instância primária.

O que fazer na segunda-feira

1. Liste os pipelines de "reverse ETL" que existem só para levar histórico do S3 para o banco. Esses são os candidatos.
2. Confira a versão do seu Aurora. Se estiver abaixo de 17.11 ou 18.6, inclua o upgrade no planejamento.
3. Escolha um caso pequeno, como um relatório ou um painel interno, e faça a prova de conceito: role IAM com o recurso AuroraAnalytics, CREATE EXTENSION aurora_analytics;, foreign tables e a consulta combinada.
4. Meça antes e depois: tempo de resposta, bytes lidos do S3, custo de compute e o custo do pipeline que você desligaria.
5. Decida o que materializar com base nos dados de uso, e não por intuição.

Se você está avaliando a arquitetura de cloud como um todo, o comparativo AWS vs Azure vs GCP para startups ajuda a situar essa decisão.

Quem faz esse trabalho

Modelar, particionar e acompanhar o custo de cada consulta é trabalho de engenharia de dados e de cloud, e é aí que o ganho do recurso aparece ou não. Se o seu time não tem hoje quem conduza essa prova de conceito, esse é um bom ponto para reforçar.

Fontes e Referências

• Amazon Aurora PostgreSQL now supports direct querying of Apache Iceberg and Parquet data in your data lake, AWS News Blog, setembro/2026, aws.amazon.com
• How Aurora analytics works, Amazon Aurora User Guide, setembro/2026, docs.aws.amazon.com
• AWS enables Aurora to analyze data directly from S3, Techzine Global, outubro/2026, techzine.eu