Aurora PostgreSQL passa a consultar Iceberg e Parquet direto no data lake, sem ETL

A AWS anunciou, em post no AWS News Blog assinado por Esra, uma extensão para o Aurora PostgreSQL que elimina um problema crônico de quem mantém dados transacionais num banco relacional e dados históricos num data lake: a necessidade de mover tudo para um lugar só antes de cruzar as duas coisas. Com a extensão aurora_analytics, dá para rodar uma única query SQL que une uma tabela nativa do Aurora com um arquivo Parquet ou uma tabela Apache Iceberg que vivem no Amazon S3, sem pipeline de réplica no meio.

Quem trabalha com Aurora conhece o padrão: dados recentes ficam no banco operacional porque a aplicação precisa de latência baixa, e dados antigos migram para o data lake porque manter anos de histórico num RDS custa caro em armazenamento e em IOPS. O problema aparece quando uma consulta de negócio, ou um agente de IA, precisa dos dois ao mesmo tempo. Até agora, a saída era construir um pipeline reverso de ETL: extrair do data lake, carregar numa tabela temporária no banco, manter tudo sincronizado. Isso duplica dado, duplica custo de armazenamento e cria mais um processo para monitorar.

DuckDB embutido dentro do Aurora

A peça técnica por trás da novidade é o DuckDB, motor analítico que a Amazon passou a manter depois de incorporar a equipe da DuckLabs. Em vez de rodar como serviço separado, o DuckDB fica embutido dentro do próprio processo do Aurora PostgreSQL. Isso significa que o processamento da parte analítica acontece dentro da mesma instância que atende a aplicação transacional, sem salto de rede extra e sem exportar dado para outro serviço fazer a leitura.

Na prática, o Aurora consegue até combinar escritas ainda não commitadas da sessão atual com o conteúdo do data lake na mesma consulta, porque a parte operacional continua sendo resolvida pelo motor normal do PostgreSQL enquanto o DuckDB cuida do scan sobre Parquet e Iceberg. A recomendação do post é explícita sobre de onde vem esse ganho:

Estamos felizes em trazer a velocidade e a simplicidade do DuckDB diretamente para o Aurora PostgreSQL, para que você e seus agentes possam consultar e combinar dados operacionais e do Iceberg usando as aplicações, ferramentas e endpoints familiares do PostgreSQL já em uso.

We're excited to bring the speed and simplicity of DuckDB directly into Aurora PostgreSQL, so you and your agents can query and combine operational and Iceberg data using the familiar PostgreSQL applications, tools, and endpoints already in use.Esra, AWS News Blog

Requisitos e como habilitar

O recurso está disponível a partir do Aurora PostgreSQL 17.11 e 18.6. Para usar, é preciso:

• Criar (ou já ter) um cluster Aurora PostgreSQL numa dessas versões
• Anexar ao cluster uma IAM role com a feature AuroraAnalytics, que dá acesso ao Amazon S3 e ao AWS Glue Data Catalog
• Habilitar a extensão com CREATE EXTENSION aurora_analytics;, via psql ou pelo console do Amazon RDS

Depois disso, o acesso aos dados externos é feito com CREATE FOREIGN TABLE, apontando para o arquivo ou tabela no data lake através de um SERVER aurora_analytics_server. Um detalhe prático: o CREATE FOREIGN TABLE pode ir com parênteses vazios, porque o Aurora lê o schema direto do metadado do Parquet ou do Iceberg, sem exigir que você declare cada coluna manualmente.

CREATE FOREIGN TABLE transaction_history ()
SERVER aurora_analytics_server
OPTIONS (
 location 's3://meu-bucket/finance/transaction_history.parquet',
 format 'parquet'
);

Com isso, uma query simples já combina o operacional com o histórico sem mover nada:

SELECT merchant, category, amount, transaction_date, 'recent' AS source
FROM recent_transactions
WHERE customer_id = 'C-1001'
UNION ALL
SELECT merchant, category, amount, transaction_date, 'historical' AS source
FROM transaction_history
WHERE transaction_date >= CURRENT_DATE - INTERVAL '5 years'
ORDER BY transaction_date DESC
LIMIT 15;

Nesse exemplo do próprio post, recent_transactions guarda os últimos 7 dias dentro do Aurora, enquanto transaction_history aponta para um Parquet no S3 com 5 anos de histórico. As linhas mais recentes vêm do PostgreSQL normal; o restante é lido direto do arquivo via DuckDB. Para quem tem muitas tabelas a importar de uma vez, IMPORT FOREIGN SCHEMA cria em lote todas as tabelas Iceberg ou Parquet de uma database no Glue Data Catalog, inferindo os schemas automaticamente.

Catálogos externos via Glue Data Catalog federation

O recurso não fica preso a tabelas nativas do Glue. Usando a federação de catálogos do AWS Glue Data Catalog, dá para registrar um catálogo externo compatível com o padrão Iceberg REST Catalog (IRC) e criar foreign tables para as tabelas desse catálogo do mesmo jeito que se faz para tabelas nativas do Glue. Isso é relevante para quem já tem investimento num catálogo de terceiros e não quer migrar metadado só para ganhar essa funcionalidade: uma mesma query pode juntar dado do Aurora com Iceberg tables registradas em múltiplos catálogos.

Performance: pushdown, cache e observabilidade por query

O post descreve duas otimizações que evitam que o custo de consulta exploda conforme o data lake cresce: predicate pushdown, que filtra linhas já na leitura do arquivo em vez de trazer tudo para depois filtrar, e column pruning, que lê só as colunas pedidas pela query. Dados acessados com frequência também ficam em cache na instância do Aurora, então consultas repetidas contra o mesmo recorte tendem a responder mais rápido na segunda vez.

Para quem precisa justificar custo e performance ao time, a função aurora_analytics_stat_statements() reporta, por query, métricas como linhas escaneadas, bytes lidos do Amazon S3 e cache hits. Isso dá visibilidade real sobre quanto cada consulta está custando em leitura externa, o que ajuda a decidir se vale a pena manter o dado como foreign table ou materializá-lo.

Quando materializar em vez de consultar direto

Para padrões de acesso que exigem latência de milissegundos únicos, consultar o data lake em tempo real via DuckDB não é a resposta certa: o scan de um Parquet remoto nunca vai competir com um índice nativo do PostgreSQL. Nesses casos, o próprio post recomenda materializar o recorte quente numa tabela nativa do Aurora, usando CREATE TABLE AS SELECT, INSERT INTO ... SELECT ou MERGE INTO. A tabela materializada passa a se comportar como qualquer tabela PostgreSQL comum, com os índices e a latência que a aplicação espera.

Vale notar a divisão de trabalho entre instâncias do cluster: as queries de leitura sobre o data lake, materializadas ou não, podem rodar tanto no writer quanto em qualquer read replica, o que ajuda a tirar o peso de scans analíticos da instância que atende escrita transacional. Já os comandos de materialização, por escreverem dado no Aurora, só rodam no writer.

Disponibilidade e custo

O recurso já está em todas as regiões comerciais da AWS, incluindo São Paulo (sa-east-1), e nas regiões AWS GovCloud (US). Não há cobrança adicional pela extensão em si: o custo extra vem do compute incremental do Aurora consumido pelas queries e das request costs do Amazon S3 ao ler os arquivos do data lake.

Para arquiteto de soluções e DBA que já mantém pipeline de réplica entre Aurora e S3 só para dar suporte a relatórios ou dashboards, essa é a conta que muda primeiro: comparar o custo do pipeline atual (infraestrutura de ETL mais engenharia de manutenção) contra o custo marginal de compute e leitura do S3 sob demanda.

O ganho mais imediato é para quem constrói agentes de IA que precisam raciocinar sobre dado vivo e dado arquivado ao mesmo tempo, caso em que prever e replicar antecipadamente todo dataset que o agente pode precisar é inviável. Para esse cenário, ter o Aurora como ponto único de consulta, falando o SQL que a aplicação já usa, evita duplicar a camada de acesso a dado só para cobrir o caso do agente.

Fonte: AWS News Blog