EDB将分析能力集成到Postgres数据库为AI智能体提供支持

把业务数据库和分析平台分开部署，长期以来都被奉为架构上的金科玉律。但如今，当AI智能体需要持续读取、理解数据并直接做出行动时，这个“最佳实践”反而成了最大的绊脚石。数据仓库和数据库厂商们终于意识到，是时候做出改变了。

就在Databricks推出基于Neon Postgres的湖仓事务与分析处理（LTAP）方案、试图拉近OLTP与OLAP之间距离的数周后，EnterpriseDB（EDB）也跟进了。他们的托管型EDB Postgres AI数据库服务也新增了融合分析能力——目标方向几乎一样。

这场战役的导火索很明确：企业AI智能体需要直接操作最新鲜的业务数据，不可能再等数据管道慢慢同步或生成副本。但两家厂商的出发点其实天差地别。

EDB首席工程官Max Romanenko点明了核心差异：“Databricks从湖仓往外扩展，想通过Lakebase把事务处理能力塞进去。我们刚好相反——我们从Postgres的操作层出发，那里才是企业运行最关键业务负载的地方。”也就是说，Databricks试图把交易能力搬到大数据仓库里，而EDB则是把分析能力“嫁接”到交易数据库上。

这就衍生出两种截然不同的架构思路。EDB的做法是：把Postgres作为操作层的唯一可信数据源，然后用Apache Iceberg做个共享目录层，把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基础来访问数据，企业就无需再部署和治理多套专用数据存储系统，需要许可和安全防护的系统数量自然也就相应减少。

对开发者和数据工程团队来说，这套方案也能简化日常工作。Walter认为，这种体系减少了开发者需要集成和维护的系统数量，同时还消除了在事务系统和分析系统之间来回搬运数据所需要的大量管道工作。Pratt补充道：“零ETL意味着几乎不需要搭建和维护数据管道，工程师终于可以把精力集中在真正创造价值的工作上了。”

当然，EDB和Databricks并不是这个赛道上唯一的玩家。Snowflake正通过支持开放表格式，持续扩展对操作型工作负载的支持；微软则借助Fabric平台，把事务处理和分析服务整合到更广泛的数据架构体系中。

不过，这次更新不只是融合分析这么简单。EDB还正式发布了“智能体数据库”功能——简单说，就是让AI来自动化处理日常数据库管理任务。这个系统会持续监控数百项运营和性能指标，一旦检测到异常就推荐修复措施，如果企业策略允许，它还能直接自动执行修复操作。据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等消耗量计费的云平台更友好。但分析人士也提醒，可预测不代表更便宜。高速操作数据处理对硬件要求较高，整体硬件成本可能反而高于廉价的湖仓对象存储方案。企业在评估时需要综合权衡。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：EDB将分析能力集成到Postgres数据库为AI智能体提供支持要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题