Image: Amazon Web Services
Why it mattersTeams that run Postgres can read the data lake from the same database their app already uses, which removes an entire ETL pipeline and the people who maintain it.
The team that moves data from the lake to Postgres every night has a smaller job this week. Amazon Aurora PostgreSQL has embedded DuckDB inside the database engine, and one SQL statement can now read operational rows and Parquet or Apache Iceberg files in S3 at the same time.
AWS Principal Solutions Architect Esra Kayabali announced the feature in general availability on 30 September 2026, on the AWS News Blog. It works on Aurora PostgreSQL 17 from version 17.11 and on Aurora PostgreSQL 18 from version 18.6, and is live in every commercial AWS Region and in AWS GovCloud (US). AWS says the feature costs nothing on top of Aurora compute and the S3 request charges a query already generates.
What the capability does
A team turns the feature on with an extension called aurora_analytics and an IAM role that reaches the data. From then on, Aurora reads an Iceberg table in the AWS Glue Data Catalog, or a Parquet or Iceberg file in S3 or S3 Tables, as if it were a view. AWS says the engine infers the schema from the file metadata, pushes filters and column selections down to the files it opens, and caches data a team touches often. A function called aurora_analytics_stat_statements() reports how many rows the engine scanned and how many bytes it read from S3.
AWS also supports Iceberg REST Catalog (IRC) compatible catalogs through Glue federation, which lets one query reach more than one catalog without copying data between them.
The DuckDB side of the deal
DuckDB is the engine inside the new extension. Amazon Web Services acquired DuckLabs, the company behind DuckDB, in a deal that DuckLabs described on 26 August 2026. Hannes Mühleisen and Mark Raasveldt, the two creators of DuckDB and co-founders of DuckLabs, moved to AWS to lead the technical direction. DuckLabs wrote that DuckDB and the rest of what it calls the Duck Stack stay free and open source under the MIT licence, and that the nonprofit DuckDB Foundation keeps watch over the project.
Kayabali's post says the Aurora feature is the first time an AWS service has shipped a feature powered by DuckDB inside the engine, and AWS positions DuckDB as a fit for analytical workloads under one terabyte and for data access from AI agents.
A limit worth knowing: AWS says that if a workload needs single-digit millisecond latency, the right move is to pull the data into a native Aurora table rather than read it from S3 every time. Direct read fits reporting, ad-hoc questions and dashboards. It does not replace a cache for a hot read in a product.
The practical change for a team is that one database serves both roles. The transactional data that an application already stores in Aurora and the historical data a company keeps in S3 are reachable through the same SQL. Smaller teams can skip a separate warehouse for the first terabyte of history. Larger teams can retire a batch pipeline that only exists to copy data from S3 into the operational database, or the other way around.
Source
Aurora PostgreSQL direct querying of Iceberg and Parquet data by Esra Kayabali, AWS News Blog. The acquisition is on the AWS Big Data Blog, with the DuckLabs side at DuckLabs' site.
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.
