---
title: "AWS permite consultar data lakes sem mover os dados com nova capacidade Aurora"
author: "Gustavo Ramos O. Klein"
date: "2026-10-03 06:00:00-03"
category: "Inteligência Artificial & Dados"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/10/03/aws-permite-consultar-data-lakes-sem-mover-os-dados-com-nova-capacidade-aurora/md"
---

## Resumo
- A AWS anunciou em 30 de setembro de 2026 a consulta direta do Aurora PostgreSQL a dados em data lakes.
- A capacidade alcança tabelas Apache Iceberg e arquivos Apache Parquet armazenados no Amazon S3.
- O processamento usa o motor analítico DuckDB integrado ao Aurora PostgreSQL.
- O acesso ocorre por meio de foreign tables e exige a extensão aurora_analytics.
- O cluster precisa de uma função IAM com o recurso AuroraAnalytics.
- O recurso está disponível no Aurora PostgreSQL 17.11+, 18.6+ e no Aurora Serverless v2.
- A novidade elimina a necessidade de mover os dados por um pipeline de ETL antes da consulta.

---

Em 30 de setembro de 2026, a **AWS** passou a permitir que o **Amazon Aurora PostgreSQL** consulte diretamente dados armazenados em um data lake, sem transferi-los para dentro do banco antes da leitura. A mudança elimina a necessidade de mover os dados por um processo de ETL, sigla para extração, transformação e carga, antes da consulta. A pergunta que interessa às equipes de dados é direta: o que muda quando o banco operacional consegue conversar com informações que permanecem no armazenamento original? A resposta passa pelos formatos aceitos, pelo motor responsável pelo processamento e pelas configurações necessárias para estabelecer essa ponte, descritas nos [detalhes técnicos divulgados sobre a novidade](https://www.dbta.com/Editorial/News-Flashes/Amazon-Aurora-PostgreSQL-Now-Delivers-Direct-Querying-of-Apache-Iceberg-and-Parquet-Data-in-the-Data-Lake-176838.aspx).

## A consulta chega ao dado que já está no lake

A primeira camada da novidade conecta o **Aurora PostgreSQL** a tabelas no formato **Apache Iceberg**, permitindo que as informações sejam consultadas no data lake sem uma cópia prévia dentro do banco. Iceberg é um formato usado para organizar tabelas de dados armazenadas fora do banco operacional, e a capacidade anunciada pela AWS trata essas tabelas como uma origem que pode ser lida pelo Aurora. O acesso é de somente leitura, segundo o registro oficial da funcionalidade, o que delimita a proposta: o recurso foi criado para consultar dados existentes, não para transformar o Aurora em um destino de escrita para esse conteúdo externo. Essa distinção ajuda a separar a novidade de uma migração tradicional de dados.

Essa conexão também alcança arquivos em **Apache Parquet** mantidos no **Amazon S3**. Parquet é um formato de arquivo para armazenamento de dados, e a implementação permite que o esquema, isto é, a estrutura de colunas e tipos reconhecida durante a leitura, seja obtido automaticamente a partir dos metadados dos próprios arquivos. Na prática, a equipe não precisa tratar cada consulta como uma operação de cópia para dentro do Aurora antes de acessar as informações. O dado permanece no local em que foi armazenado, enquanto a consulta é encaminhada para essa origem. A AWS, portanto, aproxima duas formas de organização de dados sem afirmar que elas passam a funcionar como uma única base de escrita.

Para as tabelas organizadas com **Apache Iceberg**, há ainda uma exigência de compatibilidade com catálogos baseados no **Iceberg REST Catalog**, conhecido pela sigla IRC. Um catálogo, nesse contexto, funciona como o serviço que apresenta ao mecanismo de consulta as tabelas disponíveis e os metadados necessários para encontrá-las. A AWS informa que o novo recurso aceita catálogos compatíveis com essa interface REST, o que define uma condição de interoperabilidade para a arquitetura. A ponte, portanto, não depende apenas do formato dos dados: ela também precisa localizar e interpretar as tabelas por meio de um catálogo aceito, conectando a camada de organização ao banco que fará a consulta.

## O motor e a porta de entrada da integração

Por trás do processamento está o **DuckDB**, motor analítico integrado ao **Aurora PostgreSQL** para executar consultas sobre os dados do lake. Um motor analítico é a parte responsável por interpretar a consulta, acessar os arquivos ou tabelas e produzir o resultado solicitado. A AWS incorporou essa capacidade ao Aurora para que a leitura dos dados externos ocorra dentro do fluxo de consulta do banco. A descrição divulgada não promete um índice de desempenho nem apresenta uma comparação de velocidade; ela define a forma de execução. O ponto técnico é que o processamento analítico passa a contar com um componente especializado sem exigir que os dados sejam previamente carregados no armazenamento operacional.

Essa escolha também tem um contexto próprio dentro da estratégia da **Amazon**: o **DuckDB** foi adquirido pela companhia em agosto de 2026, segundo a publicação japonesa Gihyo. A mesma fonte afirma que a integração permite executar consultas ao data lake sem provisionamento, dimensionamento ou ajuste adicional de infraestrutura. Provisionar significa preparar recursos para que uma carga de trabalho funcione, enquanto dimensionar envolve ajustar esses recursos à demanda. A proposta apresentada pela AWS é concentrar o trabalho de consulta no mecanismo incorporado ao Aurora, evitando que a equipe precise criar uma camada separada apenas para iniciar esse processamento. Esse detalhe ajuda a entender por que a novidade é uma mudança de conexão entre serviços, e não somente uma nova opção de formato.

O acesso aos dados externos é realizado por meio de **foreign tables**, ou tabelas estrangeiras, dentro do **Aurora**. O nome descreve tabelas que representam uma origem fora do armazenamento principal do banco, permitindo que a consulta seja formulada a partir da interface do Aurora enquanto os dados continuam no local de origem. A implementação técnica transforma a tabela estrangeira na porta de entrada da leitura, estabelecendo o diálogo entre o banco e o conteúdo do data lake. Como a funcionalidade foi descrita como somente leitura, essa porta serve para buscar informações e não para atualizar os arquivos consultados. A arquitetura mantém, assim, uma separação clara entre a referência criada no banco e o dado armazenado fora dele.

Para que essa porta seja aberta, o cluster precisa receber uma **função IAM** com o recurso **"AuroraAnalytics"**, além da ativação da extensão **"aurora_analytics"**. IAM é a camada de permissões usada para definir quais acessos um recurso da nuvem pode realizar, e a função indicada pela AWS funciona como a autorização específica exigida para essa consulta. Já uma extensão é um componente ativado no banco para adicionar uma capacidade que não está disponível na configuração básica. A reportagem técnica da Heise descreve essas duas exigências ao lado do processamento feito pelo DuckDB, mostrando que a integração depende tanto do motor de análise quanto de uma configuração explícita de acesso. Sem essa preparação, a ponte entre o Aurora e os dados externos não fica habilitada.

## Versões e alcance da capacidade

Com a mecânica definida, o próximo ponto é conferir a versão instalada do **Amazon Aurora PostgreSQL**. O recurso está disponível na versão 17 a partir da atualização **17.11** e na versão 18 a partir da **18.6**. A numeração indica que a consulta direta não foi apresentada como uma função disponível em qualquer instalação antiga dessas linhas, mas como uma capacidade associada a pontos de versão específicos. Para uma equipe que mantém clusters em produção, essa informação muda a ordem da avaliação: antes de configurar permissões ou criar tabelas estrangeiras, é preciso verificar se o ambiente atende ao requisito de versão. A checagem evita tratar uma limitação de compatibilidade como se fosse um problema de configuração.

Esse recorte de versões não limita a novidade apenas a clusters provisionados de uma forma tradicional, porque a disponibilidade também inclui o **Aurora Serverless v2**. Serverless v2 é a modalidade do Aurora mencionada pela AWS para ambientes que usam ajuste automático de capacidade, e sua inclusão amplia o conjunto de instalações que podem consultar os dados externos. O recurso foi disponibilizado em todas as **regiões comerciais da AWS** e também no AWS GovCloud dos Estados Unidos, de acordo com o anúncio técnico. A localização regional, portanto, faz parte da verificação operacional de cada equipe, especialmente quando a arquitetura depende de uma região específica ou de uma área destinada a cargas governamentais.

## O que muda para as equipes de dados

O objetivo declarado para essa integração é enfrentar desafios de duplicação de dados e de custos operacionais associados a pipelines de **ETL**, conforme a descrição da Gihyo. Um pipeline é uma sequência automatizada de etapas que prepara e transporta dados entre sistemas, e a duplicação aparece quando uma cópia precisa ser criada para que outro banco consiga consultar o conteúdo. Ao permitir a leitura direta, a AWS desloca a discussão da movimentação do dado para a forma de acesso ao dado. Isso não autoriza concluir que toda arquitetura ficará mais barata ou mais rápida, porque as fontes não apresentam métricas desse tipo; significa que a cópia prévia deixa de ser uma exigência para o uso dessa capacidade. O ganho descrito é de desenho arquitetural, não uma promessa numérica de desempenho.

A partir dessas condições, o primeiro passo para avaliar o recurso no **Aurora PostgreSQL** é conferir se o cluster está na atualização 17.11 ou 18.6, conforme a linha utilizada. Em seguida, a equipe deve confirmar se o ambiente está dentro das regiões atendidas e se a modalidade Serverless v2 corresponde à configuração que deseja utilizar. Essa sequência organiza a análise sem misturar compatibilidade de versão com autorização de acesso. Também ajuda a identificar antecipadamente se a implantação exige atualização do banco antes de qualquer consulta ao data lake, uma decisão que precisa ser tomada pela equipe responsável pelo ambiente e não pelo formato dos arquivos.

Depois de confirmar a versão, a configuração exige atribuir a **função IAM** com o recurso indicado pela AWS e ativar a extensão **"aurora_analytics"**. A consulta será exposta por tabelas estrangeiras, enquanto o processamento analítico ficará a cargo do DuckDB integrado ao Aurora. Esse fluxo transforma a arquitetura em uma conversa entre partes especializadas: o catálogo identifica a tabela, a referência no banco abre a porta de leitura e o motor analítico processa a solicitação. O próximo passo concreto para as equipes é validar essa cadeia em sua própria configuração, mantendo os dados no local original e verificando cada requisito técnico antes de colocar a consulta em uso.