Google Cloud 宣布在 AlloyDB for PostgreSQL 中推出 direct Iceberg access 预览版，同时 AlloyDB sync 与 Lakehouse federation 正式可用。开发者现在可以用一条 SQL 查询，直接读取云存储桶中的 Apache Iceberg 表，并与实时操作数据做 join。传统上，业务决策需要同时依赖操作数据库的实时状态和分析系统（湖仓/数据仓库）的历史上下文，这两类系统过去是分离的，现在开始快速融合。

这次更新为 AlloyDB 提供了三种方式与 borderless Lakehouse 协作。Direct Iceberg access 支持通过 bucket 路径或 Lakehouse runtime catalog 注册 Iceberg 表，注册一次后就可以像普通 PostgreSQL 表一样查询，包括与实时操作表 join。读取由 AlloyDB 列式引擎加速，运行在应用所在实例，无需单独读取实例，读到的始终是团队最新发布的数据。AlloyDB sync 从 BigQuery 复制数据到 AlloyDB，一次性或按计划刷新；副本是本地表，可以索引、从读取池服务，也能配合列式引擎和向量搜索。Lakehouse federation 直接查询原生 BigQuery 表，下推过滤、聚合和 limit，由 BigQuery 完成大部分处理；还可以指定计费项目和限制可用角色。

官方给出了性能测试结果：在 Cloud Storage 的 1 TB 数据集上，AlloyDB 直接访问 Iceberg 的聚合查询，比亚马逊的同类 PostgreSQL 兼容服务最高快 7 倍，比开源 PostgreSQL 扩展最高快 3.5 倍。Etsy 用 borderless Lakehouse 统一了 3 PB 数据，原地 join 数据，管道查询速度提升 60%。客户 Loyal Guru 的 CTO 也提到，AlloyDB 与 BigQuery 的组合提供了持续增强平台所需的敏捷性和性能。

这些能力把历史数据留在湖仓，决策发生在数据库，也就是原文所说的“行动时刻的决策”。具体场景包括：支付前的欺诈检查同时查 Iceberg 中五年交易历史和数据库最近 30 天数据；购物 agent 把实时购物车与湖仓中的终身价值和退货历史 join；定价 agent 结合实时库存与多年需求、天气历史动态调价；数据团队把整理好的表发布到 Iceberg，多个应用就地读取。Agent 只使用 AlloyDB 中授予它的表和权限。

如何选择取决于数据在哪里、应用怎么读。Direct Iceberg access 适合历史数据在 Iceberg 中，需要与实时数据 join 的场景；可以在 PostgreSQL 18 实例上启用并按文档操作。AlloyDB sync 适合应用反复读取、要求最低延迟的表，副本新鲜度由最近一次刷新决定；可以直接在 BigQuery 控制台或 psql 中选择表启动同步。Lakehouse federation 适合历史数据在原生 BigQuery 表中，由 BigQuery 承担计算；相关配置文档已提供。整体来看，应用与 AI Agent 不需要构建或维护自定义管道，就能同时对操作数据和湖仓数据采取行动。