Aurora PostgreSQL正式支持直查Iceberg与Parquet：复用数据库接口，仍需评估查询资源

2026 年 9 月 30 日，AWS 宣布 Aurora PostgreSQL 直接查询 Apache Iceberg 与 Parquet 数据的能力正式可用。应用可以通过已有 PostgreSQL 接口访问数据湖中的资料，并与 Aurora 内的业务数据结合，减少为了读取而先复制一份数据的需求。

配图为 AI 生成的概念示意图，非真实产品界面、设备照片或性能测试结果。

本次能力怎样连接两类数据

官方方案通过 PostgreSQL 外部表引用 Amazon S3、S3 Tables 或 Glue Data Catalog 中的数据，查询由嵌入 PostgreSQL 的 DuckDB 引擎参与执行。功能从 Aurora PostgreSQL 17.11、18.6 及各自更高版本提供，覆盖 AWS 商业区域和 GovCloud（美国）。

官方使用说明同时确认支持 Aurora Serverless v2，并允许将外部表与本地表联查，或把查询结果写入 PostgreSQL 表和物化视图。启用这项能力没有附加费用，但新增 Aurora 计算和 S3 请求用量仍需付费，不能理解成查询免费。

先确定什么数据必须及时

以下是本文的架构评估建议。先将场景写成具体问题：用户正在查看哪条业务记录，需要补充哪段历史信息，以及可接受多旧的数据。把“能查询”与“适合放在交互请求的关键路径上”分开验收，避免只因接口一致就忽略延迟要求。

例如一个内部查看页面需要把当前工单与历史处理记录放在一起，测试时可以先限制时间窗口和返回字段。观察单次查询的资源消耗，再增加并发；不要一开始就扫描全部历史记录，然后只看最终是否有结果。

联查之后仍要核对业务口径

两边数据的编号、时区和更新时间可能采用不同约定。准备一个很小、人工能核对的样本，检查关联前后的行数和重复情况，再扩大到真实数据量。查询没有报错，并不保证业务记录被正确连接，也不保证旧数据已经同步完成。

如果最终选择把一部分结果物化到本地，还应写清刷新频率、失败处理和读者如何判断新旧。物化可以改变读取路径，但它同时引入需要维护的副本。是否采用，应由访问频率、允许延迟与维护成本共同决定。

上线前还应针对实际数据源检查访问权限、查询计划与资源限制。此次发布减少了某些数据搬运环节，并没有免除这些验证。先用可解释的小样本建立基线，再看它是否能简化自己的系统，会比直接替换全部数据流水线更容易评估。

来源与核验

AWS官方发布（2026-09-30）；Aurora官方使用说明（2026-10-01核验）。本文于北京时间 2026 年 10 月 1 日核验，功能状态以官方后续更新为准。