AWS將DuckDB分析引擎嵌入Aurora PostgreSQL，使其具備直接查詢資料湖的功能。開發者可從Aurora查詢Amazon S3中的Apache Iceberg與Parquet資料，再與資料庫內的交易資料一起處理，不必先把資料湖中的歷史資料複製進Aurora。
企業經常把近期交易等需要頻繁存取的資料放在資料庫，較久的歷史紀錄則留在S3資料湖。過去應用程式若要一起使用兩邊的資料，通常得另外建立資料搬移流程，把需要的歷史資料複製到資料庫，流程既耗時又佔儲存成本。
現在Aurora PostgreSQL可直接讀取S3資料，既有應用程式仍能維持使用PostgreSQL連線方式與SQL語法，開發方式幾乎不用改變。
查詢時的分工很清楚：Aurora處理原本存放在資料庫內的資料，DuckDB則負責讀取資料湖內容。使用者先在Aurora建立對應到S3資料的外部資料表，之後便能像查詢一般PostgreSQL資料表一樣使用，並在同一查詢中合併Aurora與S3的資料。
支援的資料格式也相當廣泛。除了S3中的Parquet與Iceberg，也支援S3 Tables及AWS Glue Data Catalog管理的Iceberg資料表。Aurora還可透過Glue連接相容Iceberg REST Catalog的外部資料目錄，查詢由不同資料目錄管理的Iceberg資料表。
為了減少不必要的S3讀取量，Aurora會先依查詢條件縮小需要讀取的資料範圍，只讀取需要的欄位，經常使用的內容也可保留在快取中，降低重複查詢的成本。
查詢可以交由Aurora的主要節點或唯讀副本執行，因此企業可把部分資料分析工作分流到唯讀副本，避免影響線上交易效能。當應用程式需要個位數毫秒的查詢延遲，也可把需要頻繁存取的資料寫入Aurora原生資料表。
這項功能支援Aurora PostgreSQL 17.11與18.6起版本，目前已在AWS所有商業區域及AWS GovCloud（US）提供。
對資料工程團隊來說，最直接的好處是少了資料搬移流程，分析查詢變得更直接，歷史資料與即時資料可以在同一條SQL裡完成比對。
這也反映出一個趨勢：資料湖與資料庫的界線正在模糊，查詢引擎開始跨越儲存層，開發者不再需要為了分析而搬動資料。台灣使用AWS的企業，可以評估現有版本是否支援，規劃部分跨資料來源的分析查詢遷移。
