EDB 将分析能力融入 Postgres，为 AI 智能体提供支持

长期以来，将事务数据库与分析系统分离被视为良好的架构实践。然而，随着企业开始大规模部署 AI 智能体，这些智能体需要持续读取、推理并基于业务数据采取行动，数据仓库和数据库厂商越来越意识到，这种分离架构正在成为一种负担。

就在 Databricks 发布基于 Neon Postgres 的湖仓事务与分析处理（LTAP）方案、致力于拉近 OLTP 与 OLAP 之间距离的数周之后，EnterpriseDB（EDB）也为其托管型 EDB Postgres AI 数据库服务推出了融合分析能力，目标方向如出一辙。

两家厂商都在应对同一股压力：让企业 AI 智能体能够直接操作最新的业务数据，而无需等待数据管道和副本同步。但 EDB 认为，其方案出发点与 Databricks 存在本质差异。

EDB 首席工程官 Max Romanenko 表示："Databricks 是从湖仓向外扩展，试图通过 Lakebase 将事务处理能力引入进来，而我们则是从 Postgres 的操作层出发——那里本就是企业运行最关键业务负载的地方——然后从这个基础向外延伸。"

与 Databricks 以湖仓为核心的 LTAP 不同，EDB 保持 Postgres 作为操作层的唯一可信数据源，并使用 Apache Iceberg 作为共享目录层，将 Postgres 与 ClickHouse、WarehousePG 及 Spark 计算引擎相连接。在这一架构下，操作数据留存于 Postgres，历史数据和分层数据存储在 Iceberg 管理的对象存储中，各分析引擎可通过统一目录查询同一份数据，无需额外的数据副本或 ETL 管道。

Romanenko 表示，这一架构层面的差异对 EDB 而言至关重要，因为该公司的目标客户是那些希望获得 AI 与分析能力、同时又不愿将敏感数据迁移到云端托管平台的企业。"对我们来说，重点始终在于让数据保存在客户自己拥有和掌控的基础设施上。"

HyperFrame Research AI 技术栈业务负责人 Stephanie Walter 认为，EDB 对数据主权的强调"将对关注数据主权、合规监管数据及混合部署的 CIO 产生强烈共鸣"。她表示，这一方案能够让企业在自己掌控的基础设施上、更贴近数据地运行 AI 与分析工作负载，同时避免构建另一套专有数据体系。

HFS Research 高管研究负责人 Ashish Chaturvedi 认为，对于那些正在努力管控分析与 AI 预算的 CIO 来说，EDB 的融合分析方案在成本可预测性上优于 Databricks LTAP。他指出，EDB 基于核数的定价模型让成本预测更加清晰，而基于消耗量的云数据平台则会因查询量、AI 工作负载和数据处理需求的波动导致账单难以把控。

不过，Info-Tech Research Group 顾问研究员 Igor Ikonnikov 提醒道，可预测的账单不等于更低的账单。"高速操作数据处理对硬件的要求更高，相对成本也更贵，这与廉价的湖仓存储相比并不占优势。"

在数据治理层面，EDB 的架构也有望简化企业的管理负担。IDC 研究总监 Devin Pratt 表示，由于操作、分析和 AI 工作负载都可以通过统一的 Postgres-Iceberg 基础访问数据，企业或许能够避免部署和治理多套专用数据存储，从而减少需要许可和安全防护的系统数量。

对于开发者和数据工程团队而言，EDB 的融合分析方案同样能简化日常工作。Walter 指出，这一架构减少了开发者需要集成和维护的系统数量，同时消除了在事务系统和分析系统之间移动数据所需的大量管道工作。Pratt 也补充道："零 ETL 意味着几乎不需要搭建和维护数据管道，工程师可以将精力集中在真正创造价值的工作上。"

在这一领域，EDB 和 Databricks 并非唯一的参与者。Snowflake 通过支持开放表格式，持续扩展对操作型工作负载的支持；微软则通过 Fabric 平台，将事务处理与分析服务整合至更广泛的数据架构体系中。

不过，此次更新并不止于融合分析。EDB 还正式发布了"智能体数据库"功能，旨在自动化处理日常数据库管理任务。该系统能够持续监控数百项运营和性能指标，检测异常，推荐修复措施，并在企业策略允许的情况下自动执行修复操作。EDB 表示，这些自动化智能体可帮助企业将数据库优化和调优速度提升最高 10 倍。

对此，Walter 保持审慎态度："这更像是自治数据库概念的演进，而非一个全新的品类。Oracle 等数据库厂商在自治数据库能力上已深耕多年。"不过她也指出，EDB 的差异化机会在于：将这些自治能力与 AI 驱动的推理、自动化修复以及治理控制相结合，让企业能够灵活决定赋予系统多大的自主权限。

Q&A

Q1：EDB 的融合分析架构与 Databricks LTAP 方案有什么核心区别？

A：EDB 以 Postgres 作为操作层的唯一可信数据源，通过 Apache Iceberg 统一目录连接 ClickHouse、WarehousePG 和 Spark 等分析引擎，数据无需复制或经过 ETL 管道即可被各引擎查询。Databricks LTAP 则从湖仓出发，试图将事务处理能力引入进来。EDB 强调数据主权，数据始终保存在客户自己控制的基础设施上，而 Databricks 更依赖云端托管平台。

Q2：EDB 推出的"智能体数据库"功能具体能做什么？

A：该功能会持续监控数百项运营和性能指标，自动检测异常，并提出修复建议。在企业策略允许的情况下，系统还可自动执行修复操作，无需人工干预。EDB 表示，这一能力可将数据库优化和调优速度最高提升 10 倍。不过分析人士也指出，这类自治数据库能力并非全新概念，Oracle 等厂商此前已有类似产品。

Q3：EDB 融合分析方案在成本方面有哪些优势和潜在风险？

A：EDB 采用基于核数的固定定价模型，成本更易预测，适合预算管控严格的企业，相比 Databricks 等消耗量计费的云平台更透明。但分析人士也提醒，可预测不代表更便宜，高速操作数据处理对硬件要求较高，整体硬件成本可能高于廉价的湖仓对象存储方案，企业在评估时需综合考量。