Amazon Aurora PostgreSQL now supports direct querying of Apache Iceberg and Parquet data in your data lake

If you’ve ever built a data pipeline, you know the frustration: your operational database has real-time transaction data, but your analytics team needs to query historical data sitting in S3. Traditionally, this meant building ETL jobs to synchronize data between systems, maintaining duplicate copies, and dealing with consistency headaches. Amazon Aurora PostgreSQL just eliminated that problem. You can now query Apache Iceberg and Parquet files directly from your data lake alongside your live operational data—all in a single query, using standard PostgreSQL syntax.

Here’s how it works under the hood. AWS embedded DuckDB, a lightweight columnar query engine, directly into Aurora PostgreSQL. DuckDB can read Iceberg tables and Parquet files from S3, evaluate predicates efficiently, and return results that your application expects as normal PostgreSQL result sets. The integration includes support for AWS Glue Data Catalog, so your data lake metadata is discoverable without manual configuration. When you write a query that joins a table in Aurora with an Iceberg table in S3, PostgreSQL pushes filtering and aggregation down to DuckDB—the engine handles the work where the data lives, then returns only relevant results. No intermediate data movement. No separate query engine context-switching.

Why does this matter practically? Consider a real scenario: an e-commerce company wants to analyze customer lifetime value by joining current customer accounts (in Aurora) with the past three years of transaction history (Iceberg tables in S3). Previously, they’d either replicate all historical data into Aurora (expensive and slow to update) or run separate queries and join results in application code (error-prone and inefficient). Now, they write one SQL query that feels native to their PostgreSQL database, and the system intelligently pulls from both sources. The same logic applies to fintech companies reconciling live ledgers with archived transactions, healthcare systems correlating current patient records with historical claims, or SaaS platforms analyzing user behavior across real-time events and historical datasets.

The practical benefits extend beyond query convenience. You reduce operational overhead—no ETL maintenance burden. You lower costs by keeping cold data in cost-effective S3 storage instead of expensive database storage. You ensure data freshness since you’re querying the source directly, not a stale replica. And critically, your team can use SQL—the language they already know—instead of learning Spark or other data lake query tools. If you’re growing your data lake alongside your operational database and tired of building bridges between them, this capability is worth exploring immediately.