通过将分析引擎直接嵌入其托管PostgreSQL服务，亚马逊消除了长期分隔业务应用与其归档数据的抽取-转换-加载管道。
第一批倒下的，是数据的副本。亚马逊云服务(AWS)正在教会Aurora PostgreSQL就地读取Apache Iceberg数据湖，让应用把实时交易记录与历史归档拉入同一个查询结果，而无需复制任何数据。
承担重活的引擎是DuckDB,AWS已将其嵌入Aurora PostgreSQL内部。由于分析引擎常驻于数据库管理系统之中，由处理当前交易的同一家服务发出的查询可以直接向外触及Iceberg表——这一方式不需要复制的数据集，也不需要抽取/转换/加载(ETL)管道来维持两个世界的同步。
这一能力瞄准的是多年来塑造企业数据架构的一道分界线。业务型数据库为持续、小型、改变状态的写入而调优；分析系统则为扫描海量历史而调优。桥接两者传统上意味着把生产数据复制出来，转换后加载到另一个存储中——既产生重复存储，又在交易落库与成为可查询历史之间存在时滞。通过让Aurora PostgreSQL直接查询Iceberg,亚马逊把这一中间层压缩掉了：交易系统与历史档案从同一个地方即可读取。
被消除的每一条管道，同时也是一条不再需要在业务数据库与其归档之间被监控、重试或修复的定时作业。对数据平台团队而言，这是运维面积的净减少，而非增加。
该功能于9月30日发布，把Aurora PostgreSQL变成了实时数据与归档数据的单一查询地址：流行的Apache Iceberg数据湖充当历史层，DuckDB在托管数据库内部提供分析火力。对AWS客户而言，其意义非常直白：应用的当前交易与其自身历史之间的距离，刚刚被缩短了。
从行业视角看，这次发布并非一个孤立的功能点，而是湖仓一体趋势在托管数据库侧的一次落地。过去数年，Apache Iceberg逐渐成为开放表格事实标准，各大厂商围绕它构建目录、引擎与治理能力。AWS选择不去新建一个分析服务，而是把DuckDB这样的轻量级嵌入式分析引擎装进已有的事务型托管数据库，本质上是在向客户传递一个信号：分析不必搬家，历史数据不必复制，查询可以在数据所在的协议之上直接发生。对于已经在S3上沉淀了大量Iceberg表的企业，这大幅降低了试用门槛——不需要新开集群、不需要迁移数据，用现有的Aurora PostgreSQL连接串就能跑通第一条跨层查询。
对AI算力与数据平台的买家来说，这一变化的实际意义在于成本结构与延迟模型的重算。传统架构下，为支撑模型训练特征回填、报表和审计需求，企业往往维持一条或多条常驻ETL链路，并为其支付双份存储与持续运维成本；管道的延迟还决定了特征数据的新鲜度上限。现在，若实时层与历史层可以在同一查询地址内拼合，买家可以重新评估：哪些下游副本是真正必要的，哪些只是历史包袱。在规划GPU训练集群的数据供给时，数据准备环节的简化往往意味着更短的迭代周期与更少的闲置算力浪费——这比单纯比较每卡小时报价更能影响总体拥有成本。
当然，采购决策仍需冷静。嵌入式分析引擎擅长的是扫描密集型查询，并非要取代专为超大规模并发分析而建的独立数仓或湖仓查询引擎。买家应评估自身的查询模式：如果绝大多数分析负载是低频、批量的历史扫描，嵌入方案可能绰绰有余；如果存在高并发、亚秒级交互式分析需求，独立的分析集群仍不可替代。此外，跨系统直接查询意味着网络与I/O路径变长，对延迟敏感的核心交易路径应与历史扫描负载做好隔离与容量规划。建议在采购与架构评审中，把“能否消除一条ETL管道”量化为具体的人时与存储开支，而非停留在概念层面。
【真实行情数据】该型号当前无在售挂价数据，暂无可比价格带，行情详见报告编号AIXX-CLOUD-20250930-014。
Q: 这次发布的核心机制是什么，涉及哪些关键组件？
A: AWS把DuckDB分析引擎直接嵌入Aurora PostgreSQL,使其能就地查询Apache Iceberg数据湖中的历史数据，无需复制数据集，也无需ETL管道，功能于9月30日发布。
Q: 对企业数据团队最直接的好处是什么？
A: 交易与历史可在单一查询地址内读取，每条被消除的ETL管道意味着更少的定时作业需要监控、重试或修复，运维面积净减少，同时消除了副本存储与数据落库到可查询之间的时滞。
萬安算交所 AIXX · 算力硬件实名会员制交易平台 · 进入货源大厅