收购 Neon 后，Databricks 与 Google 的数据库竞争加剧

据报道，Databricks 以数十亿美元协议收购 Neon，推动 Databricks 与 Google 的竞争进入运营型数据库市场。这笔交易于 2025 年 5 月公布，后续已完成交割。随着 Neon 的技术以 Lakebase 的形式出现在 Databricks 内部，其影响变得更加清晰。

这并非又一次普通的数据库收购。Databricks 的核心定位一直围绕分析、机器学习和面向大规模处理的数据存储。Neon 则为其带来了一个兼容 PostgreSQL 的系统，用于处理应用程序每秒产生的实时交易。

此举让 Databricks 更加接近 Google Cloud、Amazon Web Services、Microsoft 和 Snowflake 的竞争阵地。各家公司都希望掌控 AI 智能体底层的数据层。Google 已提供 AlloyDB、Cloud SQL、Spanner、BigQuery、Vertex AI 及其智能体开发工具。

核心问题已不再是 Databricks 能否分析企业数据，而是它能否成为 AI 应用创建、更新、治理和分析这些数据的平台。

Neon 交易填补了关键空白

Neon 为 Databricks 提供了其 lakehouse 平台此前不具备的运营型数据库架构。

Databricks 于 2025 年 5 月 14 日宣布达成收购 Neon 的协议。其收购声明将 Neon 描述为一家面向开发者和 AI 智能体打造无服务器 PostgreSQL 服务的公司。

PostgreSQL 是一种开源关系型数据库，应用程序用它存储结构化且频繁变化的信息。它支持常见的 SQL 查询、事务、扩展功能，以及庞大的开发者生态。

Neon 通过将计算与存储分离，为云基础设施重新设计了 PostgreSQL。数据库处理能力可独立扩缩容，而持久化信息则保留在共享存储中。工作负载可以缩减闲置计算资源、创建隔离分支，并在不复制整个数据库的情况下配置新环境。

这种模式对 AI 生成的软件至关重要。人工开发团队可能会为生产、测试和预发布环境创建数个数据库；而自动化编程智能体则可能在同一时间段内生成大量临时项目、分支、测试和数据库实例。

Neon 在交易公布时表示，其服务上大多数新数据库已由 AI 智能体创建。Databricks CEO Ali Ghodsi 此后告诉 Axios，Neon 称智能体创建了其 80% 的数据库。

这一数据来自 Neon，而非独立审计。不过，它解释了其中的战略逻辑。Databricks 收购的不只是面向传统企业应用的 PostgreSQL 兼容能力，更是为机器速度的软件创建而设计的基础设施。

Neon 的创始人自 2021 年创立公司以来一直在推进这一架构。该公司的交易公告称，其最初目标是打造一项开发者乐于使用的云原生 PostgreSQL 服务。

对 Databricks 而言，Neon 补齐了三个缺失的组件。

首先，它提供了事务型存储。Databricks 此前专注于分析型工作负载，即企业处理大规模历史数据或流式数据的场景。运营型应用则需要更低延迟的读写能力，以及可靠的事务处理。

其次，Neon 提供了面向开发者的资源配置模式。数据库可以作为应用资源出现，而非需要人工管理的基础设施项目。当智能体自动创建环境时，这种差异尤为重要。

第三，Neon 为其进入 PostgreSQL 市场提供了切入点。开发者已熟悉 PostgreSQL 工具、驱动程序、扩展和查询语法。Databricks 可以扩展其平台，而无需用户接受完全陌生的编程模式。

这笔收购也延续了 Databricks 收购基础性技术的模式。MosaicML 增加了生成式 AI 训练能力；Tabular 带来了与 Apache Iceberg 和开放数据格式相关的专业能力；Neon 则补充了运营型数据库。

这些交易共同揭示了更广泛的野心：Databricks 希望掌控从原始企业数据到生产级 AI 应用的更多路径。

该公司仍依赖底层云基础设施。Databricks 运行在 AWS、Microsoft Azure 和 Google Cloud 之上。Neon 并未消除这种依赖，而是为 Databricks 增加了一层软件能力，能够影响客户如何使用这些云服务。

这一差异构成了本文的核心张力：Databricks 仍是主要云服务提供商的合作伙伴，同时也日益与其数据库和 AI 服务展开竞争。

为什么 Databricks 与 Google 的竞争如今涵盖 PostgreSQL

Databricks 与 Google 的关系既包括基础设施合作，也包括围绕 AI 应用工作负载的直接竞争。

Databricks 与 Google Cloud 已合作多年。客户可以在 Google Cloud 上运行 Databricks，将其连接至云存储，并将工作负载与 BigQuery 和 Vertex AI 等服务集成。

这一合作关系仍具有重要商业价值。企业很少会因为某一家供应商推出新数据库，就替换整个云环境。它们通常会结合多家提供商的基础设施、数据平台、模型和应用。

Neon 仍会带来竞争压力，因为 Google 销售自有的 PostgreSQL 服务。Cloud SQL 提供托管 PostgreSQL，而 AlloyDB 则是一种为高要求云工作负载设计、兼容 PostgreSQL 的数据库。

Google 还将 AlloyDB 定位为生成式 AI 应用的基础。其AlloyDB AI 路线图包括语义搜索、向量索引、自然语言查询及与模型服务的连接。

向量索引会组织文本、图像或其他内容的数值表示。应用程序利用这些表示来检索与用户请求相关的信息。

Google 的优势来自垂直整合。客户可以将 AlloyDB 与 Gemini 模型、Vertex AI、身份控制、网络、可观测性和 Google 的智能体开发工具结合使用。单一提供商运营了其中的大部分技术栈。

Databricks 提供了不同的主张。它将自身定位为可跨基础设施提供商运作的多云数据与 AI 层。Lakebase 将这一主张延伸至运营型 PostgreSQL。

这为企业买家带来了两条竞争路线。

Google 的路线从云端开始。客户使用 Google 基础设施、Google 数据库、Google 模型和 Google 管理服务，整合深度成为主要吸引力。

Databricks 的路线则从数据平台开始。客户通过 Databricks 使用受治理的信息，在云服务和模型提供商之间进行选择，并在既有分析型工作负载旁构建应用。

两种方式都无法消除复杂性。Google 客户必须决定希望将应用与单一云服务绑定得多紧；Databricks 客户则必须评估，其跨云抽象是否能提供足够的运营一致性。

Neon 收购提高了赌注，因为应用数据库往往会成为持久的架构承诺。迁移一个模型端点或许相对容易，但迁移一个承载多年应用依赖的事务型数据库则难得多。

PostgreSQL 兼容性能够减少部分迁移摩擦，但并不能保证可移植性。托管服务会围绕核心数据库引入专有的身份验证、网络、监控、分支、复制和 AI 集成能力。

Google 可以主张，AlloyDB 能够与其云控制体系和 Gemini 服务深度且成熟地集成。Databricks 则可以主张，Lakebase 能在其平台内将运营数据与分析、治理和 AI 连接起来。

这种差异会在 AI 客户支持应用中变得具体。应用可能会在 PostgreSQL 中存储账户、对话状态、权限和工作流状态，同时还可分析历史互动，并为智能体检索相关文档。

使用 Google 时，应用可能会组合 AlloyDB、Vertex AI 和 BigQuery；使用 Databricks 时，Lakebase 可以处理事务，而 lakehouse 则支持分析、模型评估和受治理的检索。

买家选择的不只是数据库性能。这一决策还会影响应用状态存放的位置、智能体获取上下文的方式，以及由哪个平台治理访问权限。

这正是为什么核心关键词的意义超过单一收购案。Databricks 与 Google 的竞争反映了双方围绕企业 AI 应用底层控制点的争夺。

Databricks 无需取代 Google Cloud 的基础设施就能形成压力。它只需要让客户将 Databricks 视为其主要的数据与 AI 控制平面。

AI 智能体改变了数据库必须处理的内容

Neon 真正的战略价值在于，能够为自动化软件工作流配置、分支和扩缩容数据库。

传统数据库运维假设大多数基础设施决策由人来做。工程师申请数据库、配置访问权限、建立备份并创建开发环境。

AI 编程智能体压缩了这一周期。它们能够生成应用、运行测试、修改架构，并在有限人工干预下部署预览环境。数据库层必须能够响应，同时不能成为管理瓶颈。

无服务器配置有所帮助，因为无需通过冗长的人工流程分配容量。工作负载到达时可以启动计算资源，活动停止时则可缩减资源。

分支同样重要。数据库分支能为开发者或智能体提供从既有状态派生的隔离环境。可以在不改变生产记录的情况下测试变更。

设想一个智能体接到任务，要为内部应用增加订阅管理功能。它可能会修改架构、创建测试账户、运行迁移脚本并验证查询。

直接在生产数据库中执行这些步骤并不安全。为每次尝试创建传统副本会消耗时间和存储。基于分支的工作流提供了更清晰的边界。

这一架构也支持预览应用。每一项拟议代码变更都可以获得独立的应用部署及相应的数据库状态。审查者可在变更进入生产环境前检查可运行的软件。

这些模式解释了 Databricks 为什么需要的不只是通用 PostgreSQL 托管服务。Neon 围绕快速创建、独立计算和数据库分支设计了其服务。

Lakebase 将这一设计带入 Databricks。它把兼容 PostgreSQL 的运营型数据库与一个已用于数据工程、治理、分析和机器学习的平台连接起来。

其潜在收益在于，缩短应用实时状态与其分析上下文之间的路径。智能体可在利用当前事务记录的同时，从更广泛的企业数据集中调用受治理的信息。

Databricks 将其治理层称为 Unity Catalog。在这一语境下，治理涵盖对数据和 AI 资产的发现、权限、血缘和策略控制。

统一目录并不能自动解决应用安全问题。运营型数据库有各自的用户、连接规则、事务边界和故障模式。不过，共享身份与策略集成可以减少重复的管理工作。

Google 正通过不同的架构走向类似目标。AlloyDB 支持 PostgreSQL 工作负载，而 Google 则将数据库与 Gemini、Vertex AI 和智能体框架连接起来。

Google 的公开文档称，AlloyDB AI 支持向量搜索、自然语言交互，以及调用多个模型提供商。这种广度削弱了“Neon 为 Databricks 带来独有 AI 数据库类别”的说法。

相反，Neon 帮助 Databricks 在工作流设计上展开竞争。该公司可以将数据库创建与笔记本、数据管道、应用、模型端点以及受治理的企业记录并列整合。

机制比收购新闻本身更重要。AI 智能体会增加每位开发者执行的基础设施操作数量。数据库必须成为可编程资源，能够通过自动化工作流被创建、分支和退役。

其中还存在数据引力效应。一旦应用将实时状态存储在同一个用于分析和 AI 的平台上，迁移任一工作负载都会变得更加困难。

Databricks 获得了在现有客户账户中扩展的机会。使用该平台进行分析的客户，可以为新的 AI 应用采用 Lakebase。这一决策可增加存储、计算、治理和模型服务的使用量。

Google 面临相反的机会。已经投入 Google Cloud 的客户，可以使用 AlloyDB 和 Vertex AI 进行构建，无需再增加另一个平台控制平面。

因此，databricks google 之间的竞争聚焦于开发者便利性和企业控制力。两家公司都希望让自己的平台成为 AI 应用连接可信业务数据的默认场所。

胜出的数据库不会仅凭智能体品牌而被选中。它必须在真实工作负载下提供可预测的事务、恢复能力、可观测性、网络安全、区域可用性和可控成本。

收购并未消除运营风险

Databricks 仍需证明，Neon 面向开发者的架构能够在大规模场景下满足企业级生产要求。

这次收购带来了技术和工程人才，但并未让 Databricks 一夜之间拥有数十年的运营型数据库信誉。

分析平台和事务系统的故障方式不同。分析查询有时可以在延迟后重试；失败的事务则可能中断支付、重复执行操作，或导致应用状态不一致。

企业买家将考察恢复目标、复制、维护行为、连接处理、区域覆盖和工作负载隔离。他们还会测试智能体造成突发流量时的性能。

计算与存储分离提供了灵活性，但也带来了取舍。数据库必须在持久存储与活跃计算之间高效传输信息。冷启动、缓存行为和网络路径都会影响延迟。

分支同样需要明确的控制措施。智能体不应仅仅因为能够创建隔离的数据库环境，就获得对生产记录的不受限访问。

组织需要制定策略来掩码敏感信息、限制分支创建、让临时资源过期，并审计自动化变更。环境数量可能会成为治理问题。

开源问题又增加了一层不确定性。Neon 围绕 PostgreSQL 和公开可用技术建立了自身定位。被大型平台收购，可能引发对未来兼容性或产品方向的担忧。

Databricks 的历史根植于开源项目，包括 Apache Spark 和 Delta Lake。这一背景支撑了其可信度，但客户会根据实际行为而非历史作出判断。

他们应关注 Neon 的核心开发是否仍可访问，以及标准 PostgreSQL 工具是否能继续无需重大修改即可运行。专有集成能够增加价值，同时也会提高迁移成本。

Google 面临同样的信任问题。AlloyDB 是 PostgreSQL 兼容产品，而不是在每个细节上都完全一致的发行版。其最强功能依赖于 Google 的托管环境。

双方的可移植性主张都值得谨慎测试。SQL 兼容性并不涵盖运营工具、身份系统、备份、可观测性或 AI 专用扩展。

竞争压力也不仅来自 Google。Databricks 宣布 Neon 交易后不久，Snowflake 收购了 PostgreSQL 专家 Crunchy Data。

Snowflake 的一份监管文件称，该公司于 2025 年 6 月完成了这项收购。这一时间点表明，运营型 PostgreSQL 已在各类数据平台中成为战略重点。

Snowflake 的回应使 Databricks 无法独自定义这个市场。它可以将 Crunchy Data 的专业能力与自身的分析、应用和 AI 服务结合。

AWS 通过 Amazon Aurora 及其更广泛的数据库产品组合，仍是另一股重要力量。Microsoft 可以结合 Azure 数据库、Fabric、Databricks 服务以及与 OpenAI 的合作关系。

这个拥挤的市场对买家有利，因为它会推动更快的发展。但它也让产品比较变得更难。每一家供应商都将其数据库描述为已为 AI 智能体做好准备。

买家需要与真实工作负载相关的证据。一项有用的评估应包括事务延迟、恢复测试、分支创建时间、连接限制、管理工作量，以及需求波动下的表现。

团队还应测试数据移动。应用可能需要将运营记录用于分析、模型评估或检索。架构应展示这些记录能多快可用，以及治理策略如何随之应用。

关于智能体采用率的供应商主张也需要同样谨慎对待。由自动化工具创建的数据库，并不一定意味着它支撑了有价值的生产应用。

重要指标是持续的工作负载增长、活跃的生产数据库、留存率、可靠性和客户扩展。Databricks 尚未公开提供足够细节来解答这些问题。

此外还存在战略整合风险。当团队花费数月适配身份验证、计费、支持和治理系统时，被收购产品可能失去发展势头。

Neon 在加入 Databricks 后仍持续发布产品更新，这表明开发仍在积极推进。然而，持续发布并不能证明每位 Databricks 客户都能在不作架构妥协的情况下采用 Lakebase。

独立分析将这次收购描述为让 Databricks 更接近超大规模云服务商的一步。一项数据库评估指出，PostgreSQL 能力使 Databricks 的竞争范围超越了传统的数据管理领域。

这种扩张在战略上颇具吸引力，但也提高了预期。Databricks 现在必须与已运营关键业务数据库多年的供应商竞争。

这次收购让 Databricks 成为这场竞争中可信的参与者。生产环境中的证据将决定它能否成为持久的数据库领导者。

三个信号将显示谁在取得进展

产品可用性、生产采用率和竞争整合将决定 Neon 是否改变市场。

第一个信号是 Lakebase 在正式发布后的采用情况。预览阶段的兴趣可能反映实验，而生产使用则需要安全审查、运营测试和组织层面的投入。

客户应寻找支撑面向客户应用的具名部署案例。最有力的案例将包含可量化的工作负载特征、恢复要求，以及与 Databricks 治理能力的集成。

现有 Databricks 客户账户内的持续扩展，将强化该公司的战略。这将表明，分析客户认为将运营工作负载加入同一平台具有价值。

采用有限则会削弱这一论点。这将表明，即便企业将 Databricks 用于分析和 AI，它们仍更倾向于成熟的数据库服务。

第二个信号是 Google 通过 AlloyDB 及其智能体平台作出的回应。Google 已拥有广泛的数据库产品组合，因此其回应无需直接提及 Databricks。

有意义的指标是 AlloyDB、Gemini、智能体工具、BigQuery 和治理服务之间更紧密的联系。Google 可以将垂直整合打造为对 Databricks 最有力的回应。

其PostgreSQL AI 功能如今涵盖向量检索、自然语言查询、模型连接和面向智能体的工作流。持续集成将巩固 Google 在已投入其云服务的客户中的地位。

Databricks 可以通过多云一致性作出回应。如果 Lakebase 在 AWS、Azure 和 Google Cloud 上的行为相似，客户便可获得替代特定供应商应用架构的选择。

这一主张需要运营验证。不同云之间的可用日期、区域覆盖、网络功能和灾难恢复选项可能存在差异。

第三个信号是 Snowflake 和其他供应商如何打包 PostgreSQL。Snowflake 收购 Crunchy Data 证实，Databricks 并非唯一将运营型数据库视为缺失层的一方。

关注 Snowflake Postgres 是否会成为与其数据平台紧密连接的生产服务。强劲的采用率将分散企业需求，并削弱任何简单的双公司叙事。

AWS 可借助 Aurora、Bedrock 和其成熟的开发者基础，对所有参与者施加压力。Microsoft 则可将 Azure 数据库服务与 Fabric 和 Azure Databricks 相结合。

因此，竞争将沿多个维度展开。数据库可靠性仍是基础，但平台治理、模型选择、开发者工作流和云可移植性如今都会影响同一项采购决策。

对开发者而言，眼前的好处是更多选择。团队可以比较集成式 PostgreSQL 产品，而无需放弃熟悉的 SQL、库和工具。

对企业买家而言，这一决定的影响更为长远。运营型数据库往往会成为应用的记录系统。其周边平台可能会在多年内塑造安全、分析和 AI 开发。

对 AI 产品团队而言，数据库分支尤其值得关注。编辑软件的智能体需要隔离的数据环境、受控的凭据和自动化清理。为人工节奏的资源配置而设计的数据库，可能拖慢整个工作流。

databricks google 的竞争不会由一次基准测试或一次收购决定。它将通过反复出现的生产决策来定夺：智能体在哪里存储状态、在哪里访问受治理的信息。

Neon 交易之所以重要，是因为它改变了 Databricks 的角色。该公司不再只提供位于应用数据库旁边的分析环境；它现在希望同时提供两者。

Google 在基础设施覆盖范围和集成云服务方面仍拥有重大优势。Databricks 则在企业数据团队中占据强势位置，并可跨最大的云平台运行。

这形成了一场富有成效的冲突。Google 希望由云平台来组织 AI 技术栈；Databricks 希望数据平台成为这一组织层。

评估任一路线的团队，应从真实应用开始，而不是从功能清单开始。在预期需求下测试事务行为、分支隔离、恢复、治理和模型集成。

然后问：谁掌控最关键的上下文？如果答案是云服务提供商，Google 的集成路线将更具吸引力；如果答案是数据平台，Databricks 将获得更大筹码。

这笔收购将这一架构选择转化为一项迫在眉睫的采购决策。关注 Lakebase 在生产环境中的部署、更深层的 AlloyDB 集成，以及 Snowflake 推出 PostgreSQL 的进展。这些信号将表明 Databricks 是否已建立起可持续的数据库业务，还是仅仅进入了一场拥挤的竞赛。