作者 | 吴英骏
策划 | Tina
全球数据库产业正经历蓬勃发展。尽管我们已经迈入了由生成式 AI 大模型所推动的科技新时代，但数据库行业依然表现强劲，其中的向量数据库等细分赛道也受到广泛关注。毕竟，数据库是管理数据的地方，对于任何企业来说都是刚需产品。在美国，数据库行业从 20 世纪 70 年代开始发展，Oracle 和 Db2 在当年两强争霸。过去十年间，AWS、Snowflake、MongoDB 等公司引领了云数据库时代，为数据库领域开辟了全新的未来。在中国，云数据库的概念也逐渐兴起。PingCAP 是中国数据库行业的先行者，自 2015 年成立以来，积累了大量用户，并在全球范围内展开了商业化征程。Snowflake 上市后，BAT 等大厂的大佬们纷纷选择了离职创业，拿着大量融资打造中国版的 Snowflake。
(资料图)
2021 年初，我从 Snowflake 的最直接竞争对手 AWS Redshift 离职，创立了一家名为 RisingWave（risingwave.dev）开源商业化公司，尽管目前 RisingWave 的商业化重点在北美市场，但我一直关注着中国市场，并认可其巨大的发展潜力。随着我与中美两地客户的深入交流，我逐渐理解了这两个全球最大的统一市场之间的差异。
在我看来，这两个市场的差异远不仅仅体现在人们所常说的“中国客户付费意愿弱，不愿意上云”等方面。我认为这些差异涉及到人才、资本、客户、生态等诸多方面的相互关系。在本文中，我将从各个方面阐述我的理解，并对中美数据库行业提出一些预测。
人才
大家常说，中国的人工便宜，有大量的廉价工程师。这点我是不认同的。诚然，相比于现在通货膨胀及其严重的美国，在中国招工程师还是有不小的成本优势，但是中国的工程师价格跟欧洲与新加坡相比，已经是旗鼓相当或者已经超过了，尤其算上五险一金之后，中国招工程师的综合成本实质上是高于除美国以外的绝大多数国家。
中国的软件工程师价格与新加坡、德国等国的价格相当，且远高于印度软件工程师的价格。数据来源：levels.fyi.
对于数据库行业，我认为中国的优势并不是拥有“廉价”工程师，而是拥有高效工程师。归功于基础教育，中国工程师拥有相当强的动手能力以及解决问题能力，因此可以在非常短的时间内实现美国公司要走数年才能走完的道路。当然这种高效是建立在可能牺牲掉部分严谨性之上的，这也是为什么美国的数据库公司做的产品可能不大但是保证可靠，而中国的数据库公司做的产品很大而用户却抱怨各种各样的问题。毕竟很多东西只能慢工出细活，大刀阔斧的做事可能会把诸多细节忽略。
既然中国的工程师都这么高效，为什么中国在数据库领域目前还没有出现像 Snowflake 这样的巨头？其中肯定有各种原因，但是从人才这一单一维度来讲，我认为是因为中国缺少好的产品经理。产品经理的工作是在外部与用户沟通理解需求，在内部与工程师沟通规划产品路线图。用户的需求是千奇百怪的，这点在中国这一软件行业复杂的市场上尤为明显。当面临大量不同的需求时，产品经理不应一股脑地把所有需求抛给工程团队，而是学会自己理解工程复杂度以此梳理优先级，并且学会对用户说“不”。
这就要求产品经理最好是技术出身，对数据库领域有深刻理解；同时也要求产品经理有很好的沟通能力，能够在调整用户预期的同时解决用户问题。然而，在中国的人才培养体系中，产品经理这一职位并没有被很好的重视，同时“沟通”这一门艺术在教育中有所缺失，导致很难找到既希望当产品经理又具备良好沟通能力的工程师。当产品经理无法的调节用户需求与工程开发之间的矛盾的时候，就可能导致客户流失与内部关系紧张。一旦产品经理不行，那自然产品做出来的形态也不行了。
资本
作为全球头号资本主义强国，美国的现代风险投资行业经历了百年的发展与磨练。通过各种投资案例的兴衰，风险投资机构已能够通过各种指标量化每笔投资的优劣。然而，在中国，风险投资行业起步较晚，直到 1980 年代才出现了第一个风险投资机构——中国国际信托投资公司（CITIC）。知名的美国投资公司如 IDG、红杉等进入中国则是在过去三十年内发生的事情。由于风险投资行业起步较晚，整体市场相对较早期，尽管投资者们在进行投资决策时会进行尽职调查，但更多的时候还是抱着购买彩票的心态：只要投资了十个项目中的一个能够退出，就可以获利。当然，单个项目小幅盈利是不够的，必须要有一笔大收益才能确保整体回报为正。这导致投资者倾向于寻找具有宏大叙事的项目：创始团队最好是来自 BAT 这样的大型公司的高管，而他们的产品最好是美国已上市公司的对标，或是大家都能看得到的大赛道。
此外，由于过去移动互联网时代的成功案例，人们相信用大量资金投入可以打造出大型项目，认为短期（或中长期）的资金烧耗是理所当然的，只要能击败竞争对手就能赢得最终胜利。从投资者的角度来看，这套模式似乎没有问题，但从整个社会的层面来看，却存在着低资本效率的风险。毕竟，可以对标的上市公司就那么几个，事务处理、数仓、数据湖、实时分析等大赛道也已强手如云。一旦大家都开始追逐类似的宏大叙事项目，同质化竞争就可能出现，导致价格战，并进一步让竞争变成“以低价策略批量获取客户、击败竞争对手，然后再提价”的模式。当然，我们不能完全将这一问题归咎于风险投资机构。毕竟，在中国，通过收购方式退出的案例相对较少，还没有形成完善的体系。因此，如果投资者不寻找这种宏大叙事的项目，就很可能无法收回本金。
相比之下，美国的投资者更加注重里程碑，他们希望在合理的时间范围内（通常为 18 个月）看到一家公司的各项指标是否能够稳步发展到预期的下一阶段。如果能够实现这些里程碑，他们将继续投资；如果不能，他们会考虑调整估值或寻求收购机会。实现各个阶段的指标其实是相当具有挑战性的，这就要求创业公司必须在产品方向、工程开发、客户需求等方面做出权衡。无论根据何种指标，总的方向都是寻找投资回报比最高的路径。在人工成本极高的美国，采取低价跑量的方式很难获得高投资回报比，因此人们会远离这种策略，并不断探索如何实现最大利润的方式。
对于美国的风险投资机构来说，他们相比之下更加注重项目的成功率。尽管大家都希望找到回报百倍千倍的明星项目，但我也见过一些风险投资公司愿意下注于那些被收购的项目，毕竟在美国，收购已经是一种非常成熟的退出方式。
著名风投机构 Andreessen Horowitz（A16Z）一直在向市场灌输现代数据栈这一概念。
美国的风险投资机构与中国有一个显著不同之处在于它们会积极主动地在市场中进行教育。风险投资机构在整个社会中具有巨大的影响力，他们的推销甚至能够左右买方公司高层的判断。以数据库行业为例，近年来，像 Andreessen Horowitz 等风险投资公司一直在倡导\"现代数据栈\"（modern data stack）这一概念。他们会不断地在各地宣讲，为自己的项目背书，让大家认同现代数据栈的理念。这一理念明确倡导企业将自己的技术栈切分成各个小块，然后由各个数据库公司专注于各自的领域，将单一赛道做到极致。在这样的市场环境下，很难出现中国公司常常喜欢的大一统数据库。而在中国，通常是像 BAT 这样的行业巨头在主导教育市场，他们在内部已经通过重资本投入打造了大一统系统，并且会向各个公司推销自己使用的大一统系统的理念。尽管这种做法确实能够最大化这些大公司的利益，但对于中小型企业来说，大一统系统并不一定是最优解。毕竟，用户可能仅仅只是想买一把菜刀做饭，购买功能齐全的瑞士军刀本质上就是种浪费。
客户
在最理想的情况下，市场的最佳形态应该是呈橄榄型。这样的市场结构包括一些头部企业，它们在市场中数量较小但处于主导地位，还有大量的中部企业，它们构成市场的核心，“橄榄型”的另一端则是由许多长尾小企业所构成。为什么这么说呢？因为小企业通常具有较低的付费能力，而头部企业对定制化要求较高。当市场上有大量付费能力强的中部企业时，这对于创业公司非常有利。毕竟，创业公司可以将他们的产品标准化，并通过推广渠道进入各个中部企业。数据库作为一种高度标准化的产品，在橄榄型市场中发展非常适合。美国市场就是一个橄榄型市场。相比之下，中国的整体市场起步较晚，人们购买服务的能力还不足，还并未拥有大量中部企业，而长尾小企业可能占据了市场的半壁江山，这也是人们常说的“中国客户付费意愿弱”的原因之一。云数据库作为一种服务，实际上是收取服务费的。当小企业听说云服务提供商会收取高额的“服务费”时，自然会有些不情愿。这解释了为什么人们说“中国客户不愿意上云”。
当然，我并不认为中国的云数据库市场像很多人想象的那样悲观。实际上，在我与客户沟通的过程中，购买阿里云、腾讯云等云服务的公司比例远超出了我的预期。相反，在被认为“所有企业都在云上”的美国，销售云数据库并不那么简单。尽管许多大公司，甚至银行、保险等企业都在使用云服务，但大多数企业对数据安全和隐私的要求非常高，对接受云厂商以外的独立第三方云服务仍保持谨慎态度。只要客户是一家规模稍大的公司，他们的法务部门就可能会对各种数据合规性进行审查。对于很多这类公司来说，将数据放在第三方公司那里是很难接受的。但幸运的是，目前业界普遍认可 AWS、GCP 和 Azure 这三家大型云服务提供商的资质，因此数据库公司可以采用一种全新的部署模式：BYOC（Bring Your Own Cloud），即数据库厂商在用户的 AWS 账号下提供服务，但控制平台允许在数据库厂商那里进行部署。这种折衷的模式实际上是云时代的私有化部署。
虽然中美两国的企业都购买云数据库，但他们的需求重点往往不同。根据我与两边客户接触的感受，中国用户更加注重性能，而美国用户更加注重体验。因为性能的提升通常意味着单位价格的降低，这符合中国用户的需求。而对于美国用户来说，由于工程师素质相对较低，他们更倾向于使用更简单的产品。我仍然记得在我还在 AWS Redshift 工作时，某一用户仅仅是因为竞争对手的文档更易于理解而选择离开 Redshift。尽管这可能只是个别案例，但也说明了美国用户对产品体验的重视程度。
从客户的角度来看，我认为中美两国在一个方面存在明显差异，那就是沟通方式。中国客户的沟通方式更倾向于同步，他们通常通过微信群或直接电话进行沟通，如果在同一城市的话，还会进行面对面拜访。而美国客户的沟通方式更倾向于异步。最初，客户通常只通过邮件等看似低效的方式进行沟通。在初步沟通后，可能会建立专门的 Slack 频道。视频电话几乎肯定需要提前几天预约，而面对面拜访在后疫情时代相对较少。同步和异步的沟通方式导致中美两国在客户服务方面存在巨大差异：中国的服务几乎都是保姆式的，数据库厂商会陪伴客户完成测试、部署、上线等整个过程，有时甚至会帮助客户编写代码。这种沟通方式实际上提供了超出产品本身价值的服务，但如果厂商无法控制好这种方式，可能会变相成为外包公司；而美国的服务通常是自助式的，数据库厂商只提供云上产品，客户遇到问题时需要通过系统提交工单，厂商的响应时间并不固定，除非在合同中有明确规定。这种沟通方式使厂商与客户之间更加平等，给厂商带来更多的舒适感。
生态
在中国，由于大多数公司都专注于主要领域，所以厂商之间往往存在竞争关系。而在美国，由于公司更倾向于专注于细分领域，厂商之间经常会有密切的合作关系。举例来说，作为一家流处理公司，RisingWave 的业务并不涉及 OLAP、数仓、数据湖等领域，因此我们一直与这些领域的其他公司保持良好的合作关系，并相互推荐客户。这实际上构建了一个良性生态系统：大家互相合作，在工程上进行集成，共同进行市场营销，甚至可以一起与客户进行谈判。在这种生态系统中，每个公司都知道自己的定位，当自身体量较小时，不会主动进入他人的市场。
我们再来讨论一下数据库厂商和云厂商之间的关系。在美国，数据库厂商和云厂商更多是互相促进的关系，即数据库厂商的繁荣将促进云厂商的繁荣，双方互惠互利。以 Snowflake 和 AWS 为例。Snowflake 的产品与 AWS Redshift 存在直接竞争关系，但 AWS 并没有将 Snowflake 下架。实际上，Snowflake 的兴起让 AWS 的基础设施业务（如 EC2、S3 等）大获成功，其带来的收益远远超过因 Snowflake 抢占 Redshift 市场而带来的损失。
而在中国，数据库厂商与阿里云、腾讯云等云厂商之间的关系有时比较复杂，当数据库厂商推出与云厂商产品竞争的产品时，数据库厂商往往保持警惕，因为云厂商的平台地位使得数据库厂商在竞争中处于劣势。我提到的这些并非毫无根据。如果我们不考虑具体案例，单从工程角度看国内云厂商提供给外部的接口设计，这些接口的设计会带来较大的集成难度，使得数据库厂商使用起来并不太顺畅。
趋势
总体而言，由于人才、资本、客户、生态等诸多方面因素，导致中美两国在数据库领域有着不小的差距。至于中国的云数据库公司体量能够达到美国的体量，我不好做预测，但是不少人会将时间预测在 3-5 年。我认为中美两国的云数据库行业正在趋同。有两个趋势值得注意。一个是融合型的数据库的普及，另一个是开源。
谈到融合型数据库，中美两国的理解并不相同。中国数据库企业的理解更偏“什么都能做，且什么都要做好“，这种理解经常是由大企业大客户提出的，毕竟大客户议价能力高，出价也高，当有这种需求提出的时候，数据库公司很有可能会选择满足用户需求。而美国数据库企业的理解更偏”以某一方面为核心，其他方面作为辅助“。我们以 Snowflake 来举例。Snowflake 作为上市的云数仓公司，最近正不断往事务处理、流处理等方向扩展。然而，他们在这些方向的发展节奏是相对缓慢，做出的功能只能称之为”能用“，而远远谈不上”好用“。毕竟，相信他们也非常清楚，用户实质还是在为数仓功能而选择 Snowflake，其他一切功能更多的是起到辅助作用。
说到开源，我认为中美两国的理解也存在偏差。中国数据库企业对开源的理解更多的在于希望做好做大社区，然后逐步实现社区用户向付费用户的转变。尽管美国的数据库企业中也有不少希望使用类似方式实现市场推广，但也有相当一部分的企业更看重的是开源所带来的”可信“。毕竟，美国的客户对数据安全非常敏感，当所使用的数据库产品是个黑盒的时候，客户总是会有一定忧虑。
后记
数据库市场在未来的 5-10 年时间一定会继续发展繁荣，我也坚信中美两国的数据库市场形态会越来越接近。如果想同时做中美两国乃至全球的市场，我能给出的建议是：尊重市场，求同存异，坚持自我，放手一搏。
作者简介 ：
吴英骏 ，流数据库公司 RisingWave（risingwave.dev） 创始人 &CEO。博士毕业于新加坡国立大学计算机系，为前 Amazon Redshift 工程师和前 IBM Research Almaden 研究员。常年担任数据库三大顶会 SIGMOD/VLDB/ICDE 的评审委员会成员。技术交流可以扫码关注如下公众号“RisingWave 中文开源社区”或者添加微信“risingwave_assistant”。
RisingWave 中文开源社区公众号
RisingWave 中文开源社区技术交流群