2026.09.24 | AC | Software | Data Lakehouse Leader & Anthropic

摘要

• CoCo和Agent Bricks的差异化竞争，CoCoEvolve能力。
• 客户从MongoDB、Oracle等竞对的迁移情况，数据治理影响等。

【以下为专家观点汇总，具体细节仅供参考。】

Snowflake主要业务的收入拆分情况？

收入主要分为四块。首先，最核心的部分是Computing Service。从技术角度来说，这其实就是Warehouse。Snowflake的Warehouse和传统的Warehouse有些不同。对于数据仓库或者数据库，大家通常认为Warehouse就是一个仓库，把数据或文件存进去就可以了。但在Snowflake中，Warehouse其实是一个Computing Node，是资源节点。当用户需要用SQL查询数据时，Snowflake就是通过Warehouse来完成查询的，所以Warehouse本质上是Computing Node。从Snowflake成立到现在，Warehouse的查询一直是主要收入来源，也是最核心的收入部分。客户在付费时，Warehouse这部分占了大头。具体比例我没有查到，但可以确定，Warehouse是收入的主要来源。

除了Warehouse，还有一块收入是Storage，也就是存储。用户把数据库放到云上，因为Snowflake本身就是云服务。如果是在AWS平台上，数据就存放在S3；如果是在Azure平台上，则放在Blob Storage，包括GCP也是类似。用户每个月会根据存储在Snowflake上的数据量来付费。如果用户和销售谈得好，可能会签一个容量合同，获得打包价和一定的折扣。虽然Storage也是一块收入，但和Warehouse相比，单靠Storage带来的收入并不算多。

第三块是Cloud Service。这个费用相对较低，很多大型企业和客户其实并不太在意这部分。Cloud Service主要是一些管理类的服务，比如用户管理、权限管理、维护等。如果每天Cloud Service的使用没有超过Warehouse使用量的10%，这部分其实是不收费的，可以忽略不计。但如果使用率超过了Warehouse的10%，超出的部分才会收费。所以这部分收入非常低廉，对客户来说影响不大。这是传统的Snowflake收入拆分，主要来源于这三块。现在进入AI时代，Snowflake还有一部分收入来自AI Pricing。从计费角度来说，就是Token费用，也就是AI Token的费用。Snowflake除了有自己的原生模型Architect，大部分用户还会使用Snowflake合作的模型，比如Anthropic或GPT等。因此，用户还会产生Token相关的费用。

Snowflake与其他厂商合作时，肯定会有一个成本价。Snowflake用户使用ANTHROPIC模型时，Snowflake会向用户收取费用，同时也需要支付给ANTHROPIC等合作方一定的成本。具体来说，Snowflake每收多少million的token，会收多少钱，再支付给ANTHROPIC或微软等多少钱。内部资料并没有明确写出具体比例，所以到底给了百分之多少并不确定，这部分非常机密，内部资料完全没有涉及。现在来看，主要涉及四笔费用。在AI时代，这些费用取决于客户如何使用Snowflake的AI服务。Snowflake的AI主要是Cortex Code和Co-work这两大类。Cortex Code系列，客户用得越多，产生的费用也会越高。如果Code用得很多，AI token的数据量就会上升，收费也会变高。除了token费用高，最常见的使用场景是连接Snowflake数据库，通过大模型在数据库中运行SQL或读取数据。AI用得越多，使用warehouse资源节点也会越多，传统warehouse资源节点的费用也会大幅增加。这两部分费用随着用户使用量增加而增长，Snowflake因此获利更多。借助AI，用户与大模型交互时会不断调整prompt，这意味着资源节点的使用会更多。如果没有AI，用户会更精准地写SQL语句，相对来说会更省钱。

过去三个季度Snowflake毛利率持续收缩，是否主要是AI业务增加导致的拖累？未来两个季度的趋势？

Snowflake产品毛利率在过去三个季度确实有收缩，主要原因可能是AI workload的上升，以及各种推理和云基础设施成本的不断增加。Snowflake不像AWS或微软那样拥有自己的数据中心，而是依赖云厂商。如果云厂商在基础设施上的成本增加，Snowflake的利润和毛利率就会下降。Snowflake向客户收钱是通过credits，credits的价格一般不会调整，因为涨价会影响客户体验并导致客户流失，所以credits价格通常保持稳定。但云基础设施成本上升，会导致毛利率下降，这是我的理解。产品毛利润确实略有下降，但并不特别明显。

Snowflake给客户的折扣近期有没有缩减或取消的情况？

关于客户折扣，目前没有听说有大的调整。Snowflake希望留住大客户，尤其是长期使用或使用稳定的客户，不会通过变相增加费用来影响客户。Snowflake收客户的钱不仅仅是通过credit折扣或均价变化，更像AWS的消费模式。Snowflake希望客户多用不同的服务和新功能，让资源节点和AI token消耗更多，通过这种方式让客户付更多credits，而不是单纯通过折扣调整。

是否看到比MongoDB客户因scale困难迁移到Snowflake的现象？？

以我的观察，并没有出现很多客户从 MongoDB 迁移到 Snowflake 的情况。有一些零星的小部分客户这样做，但并没有大批量用户迁移。因为本质上两者还是有区别。Snowflake 最主要的功能是 OLAP，而 MongoDB 在 OLTP 上表现不错。MongoDB 更可能作为上游的数据源，用户更多用 MongoDB 完成在线事务处理，然后将数据归档或存储到 Snowflake 上，为后续 BI 服务做准备。从这个角度看，并不是谁取代谁，也不是从一个产品迁移到另一个产品的概念。更应该从业务场景来看，MongoDB 和 Snowflake 的赛道和使用方式不同，可以将它们配成一个 workflow。

怎么看Snowflake Postgres和 MongoDB差距是否在明显缩小？

我认为差距还是存在，不一定会变得非常小，因为两者的核心和赛道不同。Snowflake 的 Postgres 最大的价值是让 OLTP 的数据更靠近 Snowflake 后端的 OLAP，减少 MongoDB 到 Snowflake 的 CDC 或 ETL。公司也希望往 OLTP 方向发展，但还要看客户的业务情况。客户一个月的使用行为和习惯，很多客户还是把 MongoDB 定义为在线数据库，即使 Snowflake 想做 OLTP，很多客户还是认为它是 OLAP，用于报表分析。

Snowflake 在引入 AI 后，不仅为客户提供 AI 功能，自己也在用 AI进行内部重组，可能会用 AI 取代一些不必要的部门。公司业绩持续增长，整体方向是不断提升业绩。MongoDB 和 Snowflake 在业务场景和赛道上有区别，更适合配合使用，而不是简单迁移或取代。Snowflake 在 Postgres 方向的发展也要看客户的实际需求，当前客户仍然倾向于将 Snowflake 用于 OLAP，MongoDB 用于在线事务处理。

您有没有观察到客户从Oracle或Teradata迁移到Snowflake的情况？

从Oracle或Teradata迁移到Snowflake的案例是有的，但并不算多。需要说明的是，Oracle、Teradata、Cloudera等并不是Snowflake的核心竞争对手。Snowflake目前的主要竞争对手还是Databri cks。客户选择Oracle、Teradata或Cloudera，往往是基于自身业务需求和运营模式，因此不会轻易迁移到Snowflake。迁移本身是一个庞大的项目，只有在有非常强的业务驱动或功能需求时，客户才会考虑迁移。如果没有明确的业务理 由，客户一般不会轻易更换平台。即使在与Databricks等竞争对手的竞争中，也只是偶尔有客户迁移过来，案例并不多。迁移的原因也不完全是产品功能，有时还涉及销售团队的人脉关系等多方面因素。

Databricks的Agent Bricks和CoCo背后同样由Claude支持，这两者未来的差异化会体现在哪些方面？

如果单纯从大模型层面来看，Anthropic为Snowflake和Databricks提供的模型功能基本一致。Anthropic不会针对不同客户单独调整模型，都是统一标准和接口。差异主要体现在与第三方厂商合作时的定位和用户业务场景。例如，Anthropic与Databricks Agent合作时，主要定位在构建生产级的Agent和AI应用；而与Snowflake的CoCo集成后，则更侧重于Snowflake的数据工程和开发任务，更聚焦于Snowflake数据库本身。不同厂商的合作对象和目标用户也有所不同。Databricks主要面向AI工程师、机器学习工程师和应用开发者，而CoCo则更多面向数据工程师、数据分析师或Snowflake的开发者，用户群体有所区别。此外，数据上下文也不同。Databricks侧重于自身的Unity Catalog、Lake Flow、Machine Learning Flow等；Snowflake则聚焦于自身的数据库、Schema、角色管理以及DBT等。两者与大模型合作的优势也不同：Databricks的优势在于Agent工厂、评估体系以及AI的部署和长期运行能力；Snowflake则能更深入地理解和操作自身环境。总体来看，Databricks更适合构建面向用户或跨系统业务的Agent，而Snowflake则更适合自身数据管道、SQL、DBT项目及其应用和语义视图等场景。虽然两者都与大模型厂商合作，但会根据各自产品特点和优势，服务于不同客户的使用场景。

关于 governance ，如何对比 Snowflake的 Horizon 和Databricks的Unity Catalog？Open Catalog sunset后的影响？

首先，OPEN CATALOG 和 HORIZON 是两个不同的产品。OPEN CATALOG 主要面向 Apache Iceberg 这种开源数据格式，而 HORIZON 更多聚焦于数据治理、安全治理和数据标签等功能。HORIZON 主要用于这些场景，这是它们的主要区别。接下来，针对 Snowflake Horizon 和 Unity Catalog（UC）之间的区别，Horizon 是 Snowflake 原生的数据治理方案，主要用于各种安全措施和治理，比如 IBAC 角色管理、数据库的 policy（如 masking policy，对敏感数据进行脱敏处理）、role access policy（控制不同角色的数据访问权限），即使执行相同的 SQL 语句，不同角色看到的结果也会不同。此外，还包括数据分类、打标签等功能，以及与 Snowflake 查询引擎的深度集成。

UC 则是 Databricks 的原生治理方案，主要服务于 Databricks 生态。Snowflake Horizon 需要通过连接外部 catalog 才能访问其他数据源。从跨平台策略同步的角度看，Snowflake Horizon 还需要进一步改进或增加设计，而 UC 与 Snowflake 并不互通，也不会自动同步到 Snowflake。在多引擎开放性方面，Horizon 更适合基于 Iceberg 的 REST 或 Polaris（北极星）等开放场景，开放性更强。UC 则在 Databricks 生态内集成更深。关于 AI 相关治理，Snowflake Horizon 结合了 Snowflake Cortex、MCP 等一系列产品，而 UC 则服务于 Databricks 的 AI Gateway 及其自有生态，集成更自然流畅。

目前客户是否在意这些治理方案的差异？

从客户角度来看，主要还是看客户群体的划分。对于基础客户来说，他们不会特别在意某个治理方案好或不好，更多是根据自身使用需求选择。如果客户原本就是 Databricks 用户，且 Databricks 提供 agent 功能，这些客户自然会优先选择 Databricks 的 agent，因为他们本身就在这个生态内。不同客户通常会使用各自平台的 agent，不会交叉使用，否则集成和人力成本都会增加。

细分来看，Snowflake 更适合对开发要求不高、上手快的客户，比如金融、医药、快消等行业，这些客户更关注现成功能，开发需求不高。相比之下，Databricks 的客户门槛更高，更适合有技术背景、需要灵活自定义和二次开发的开发者生态圈。对于急需数据工程能力的公司来说，Databricks 需要一定的知识储备和技术门槛，不是随拿随用型产品。这些客户群体的差异也影响了 agent 的使用和选择。客户群体的不同，直接影响了他们对治理方案和相关功能的需求和选择。

近期Snowflake 和 Anthropic 的合作进展？近期会如何进一步赋能 Snowflake？

Snowflake 和 Anthropic 的合作只会越来越深入。根据我的观察，客户在使用 Snowflake 时，更多会选择Claude的模型，很多用户也更愿意用 Anthropic 最新的模型。比如说，Anthropic 假设推出了 FABLE 这样的 LLM 模型，而 Snowflake 官方可能只支持到 5.0 版本，但有些客户非常关注模型的版本，甚至在 Snowflake 还没有来得及推出 5.1 版本时，就会主动询问能否用最新的 FABLE 5.1 或 Opus

1. 1 版本。这些版本虽然在 Snowflake 官方还没有上线，但由于 Snowflake 和 Anthropic 合作紧密，也会通过 public preview 或 private preview 的方式，让客户提前体验到

Anthropic 的最新模型。从这个角度来看，Snowflake 和 Anthropic 的合作会越来越密切。

CoCoEvolve主要解决客户的痛点？对于未来半年获客是不是一个重要动力？

CoCoEvolve 目前还没有 GA，它是在现有 Agent 能力的基础上，比现在的 CoCo更灵活，也能更深入地解决一些问题。现在的 CoCo主要是让客户自主管理流程，甚至可以帮助客户写程序，并不一定要和 Snowflake 数据库集成。当然，大部分用户用 CoCo 或未来用 CoCoEvolve，还是会和 Snowflake 集成，否则没必要用 Claude Code 这些 Agent。但 CoCoEvolve 和 Cortex Code 相比，更加灵活，即使不用 Snowflake 数据库，也可以单纯用 Agent 和大模型来完成一些任务。

CoCoEvolve 主要解决的是 AI 系统优化过程中依赖人工反复试错的问题，提升代码优化的效率。现在的 CODE 可能会产生幻觉，不可能做到百分之百准确。CoCoEvolve 就是要优化这些效率问题。从经验来看，之前有效的方案容易被覆盖，导致重复试错，CoCoEvolve 会不断沉淀经验，帮助用户解决 Agent 任务质量不高的问题。很多用户希望 Agent 的质量能提升，不需要反复纠正 Agent，或者出现用例失败等情况，CoCoEvolve 就是为了解决这些痛点。另外一个痛点是，普通大模型缺乏 Snowflake 环境的能力，比如无法直接操作真实对象，或者执行 AI 的 super、管道等任务。CoCoEvolve 可以更好地帮助执行 Snowflake 的 SQL，以及完成数据管道等任务。总的来说，CoCoEvolve 是把人工不断调整 prompt 或 tool agent 的低效过程，转化为可并行、可验证的自动优化闭环。