与Flink干了一架的那位创始人，写了份万字长文年终总结！

吴英骏 AI前线 2024-01-21

本文为个人观点，并不代表公司立场。

我于 2021 年年初创立了 RisingWave 这家流计算数据库公司。2023 年的临近尾声，也意味着 RisingWave 即将结束第三个年头，并踏入第四年的征程。

对于 RisingWave 来说，第三个年头从根本上不同于前两年。作为一个从零开始开发数据库的公司，RisingWave 的前两年几乎都是在系统开发中度过：我们对市场、销售的投入几乎为零，几乎所有公司资源都投向了工程与产品研发。而在即将过去的 2023 年，尽管我们保持了对市场、销售的较低投入，但我们在各个维度上都实现了快速增长，并逐步将公司带入可持续发展的轨道。无论是从开源社区增长，到生产环境落地，再到商业化变现，我们都经历了许多。在本文，我就从 RisingWave 的成长、竞争，与商业化，这三个角度，来聊聊 RisingWave 的 2023。

对于还不知道 RisingWave 是什么的朋友来说，可以将 RisingWave 理解为一个开源的分布式 SQL 流计算系统。

GitHub 链接：https://github.com/risingwavelabs/risingwave

入门教程：https://www.risingwavetutorial.com/

成长篇

从开源到生产落地

RisingWave 是一个开源项目。对于很多人来说，开源项目意味着自然流量：毕竟代码都放在 GitHub 上，似乎就会有很多人访问；只要在朋友圈或者社交媒体上发个链接，便会有很多人转发；当知道的人多了，自然会有人愿意尝试落地；随着越来越多人的使用，项目一定越来越普及，并且随之为其付费。

开源是市场策略漏斗（go-to-market funnel）的顶部。图片来源：https://a16z.com/open-source-from-community-to-commercialization/

这些听起来都很合理，并且对于一些轻量级项目来说，我们的确也见到了类似的情况。但实际上，至少对于数据库这种系统领域的项目来说，事实并非如此。RisingWave 是一个做流计算的数据库项目，面向对象为企业，而常见场景为实时监控、实时决策等核心业务。这一性质意味着落地 RisingWave 或类似的项目并非易事。

从我过去三年的经验来看，对于一个较为早期的数据库项目来说，其从“让开发者了解“到“在企业落地之间”，有着巨大的鸿沟，而这一鸿沟几乎肯定需要人的介入才可能被弥补上。换句话说，即便一个新兴项目在开源社区被广泛讨论，我们也几乎无法期待着有任何公司愿意主动在生产环境中第一个（或前几个）部署使用。为了争取前几个用户，数据库公司几乎肯定需要贴上大量工程资源，包括但不限于登门拜访、线上调试、优化代码等等。做这些，都是为了给予用户最贴心的服务。

RisingWave 的第一个企业级生产环境部署是在 2023 年年初（2022 年下半年开始沟通，历经将近半年时间）。而那时候，RisingWave 已经开发了两整年。而在没有企业级生产环境部署之前（也就是 2021 年与 2022 年），我们是如何向潜在用户推销 RisingWave 的呢？说来也很简单：我们不断说服 Apache Flink 的资深用户测试环境中使用 RisingWave 为 Flink SQL job 做测试与 debug。而这正是为什么我们在之后一段时间的宣传中会反复提及 Flink 的原因（注：RisingWave 从产品形态上与 Flink 有较大的差异化，因此与 Flink 做直接对比并非最恰当的宣传口径，我会在后面详细展开）。

相比于 Flink 这样的成熟项目，RisingWave 不可能一上来就在稳定性以及功能完备度等方面做文章。然而， Flink 的易用性，包括学习门槛、开发门槛、调试门槛、运维门槛等，都是用户时常抱怨的痛点。因此，如果用户听说有一个项目能够帮助自己更快更便捷的开发、调试自己的 Flink 程序，那自然是非常乐意。我们抓住了用户这样的心态，专门挑选对 Flink 重度依赖的大公司的研发团队进行推销。这样的合作比较轻松：当合作的双方都对合作的结果有明确的预期时，双方都会感到舒服。通过这样的方式，我们也拿到了专业用户对 RisingWave 最早期的、非生产环境下的使用反馈。

当然了，让用户在测试环境中把 RisingWave 当作调试工具来用，离生产环境落地还是差了非常远。一个新兴产品被宣传的再好，在没有用户为其站台时，也不可能吸引到高质量的、愿意在生产环境下大规模使用的、甚至愿意付费的用户。为了找到最早愿意在生产环境中使用 RisingWave 的用户，我们找到了一些初创公司。初创公司更能够对创业的艰辛产生共鸣，更愿意“抱团取暖”。当然，这并不意味着初创公司毫无顾忌的尝试一个新兴产品。对于他们来说，他们所欠缺的并不是对新鲜事物的好奇心，而是对新鲜事物的信心。既然这样，那我们就给足用户信心。我们投入了大量工程师为用户 24 小时提供技术支持，最终实现了产品落地。

我一直认为，尤其在早期，与其说 RisingWave 的产品做的有多好，不如说 RisingWave 的人工服务有多贴心。RisingWave 产品背后的 oncall 工程师们是真正的无名英雄。

摸索高速增长的方式

当有了最初的种子用户之后，RisingWave 的下一阶段便是摸索一条高增长的道路。增长对 RisingWave 至关重要。创业公司想要持续高速发展，需要做到的并不是简简单单线性增长，而是 超线性增长（注：感兴趣的朋友可以阅读 Paul Graham 的文章 Superlinear Returns：https://paulgraham.com/superlinear.html）。我不敢说 RisingWave 已经找到了一条实现超线性增长的道路，但是经过过去一整年的摸索，至少已经找到了一些可重复的样式以及固定的公式，给予了我们足够多的信心。

RisingWave 在全球范围内长期运行集群数量（只统计 Kubernetes 部署）。7 月份相比于 6 月有显著上涨主要原因可能为：1） RisingWave 发布了 1.0 版本，即第一个正式版；2）我们发布了 RisingWave 与 Flink 的性能报告（在下文讨论）。

我认为，RisingWave 如果想要实现超线性增长，那么很大程度上需要借助于开源的力量。开源对于数据库这类项目来说，最大的帮助并非是早期落地，也并非后期全面商业化，而是早中期更高速增长。为什么开源能够在早中期帮助高速增长？我们可以仔细看看开源对用户到底意味着什么。

我认为开源从本质上意味着更快赢得用户信任，并大幅降低用户尝试门槛。

早期的传统 SaaS 产品都要求用户直接联系销售团队、进行电话沟通之后，才能试用产品。这种模式将“人”这个因素引入到流程之中。当“人”被引入时，大多数潜在客户都会变得谨慎，因为大多数人对与销售沟通抱有一定抵触心态。在这种模式下，用户尝试产品的门槛高，且用户与商家间的信任关系需要依靠”人“这一因素来打磨。这便是典型的强销售模式。强销售模式下，组建销售团队成本高昂，并且不容易扩展，增长可能会遇到瓶颈。

意识到这些问题，不少新兴的 SaaS 产品将“人”这个因素从试用流程中剔除，允许用户直接输入个人信息便能够免费注册、免费试用。这种方式对于各类面向个人消费者的产品，如手机上的软件等，来说是非常奏效，但对于数据库这类面向企业的产品来说，可能还是会遇到问题。

数据库等企业级软件需要存储企业数据，而几乎所有企业都对数据安全敏感。因此，不少企业都对使用 SaaS 产品有严格的审批流程。即便企业愿意尝试使用新的 SaaS 产品，通常一开始都只愿意使用小规模测试数据来进行试错。大家不难想到，这种方式能够吸引到的用户群体实质上还是经过严格筛选，并且循序渐进的尝试产品往往意味着投入更长周期、更多精力。

开源很好的解决了这些问题。开源允许企业用户在自己的环境中几乎无风险的部署、使用产品。用户无需顾虑自己的数据安全、无需与任何销售打交道，便能够更加全面的评估产品的能力。毕竟，在开源这种模式下，用户构建信任的对象是代码，而非人。当用户遇到问题时，往往只需要在开源社区中提出问题，便可以达到详尽的答复。显然，这种方式可以被更多企业所接受，企业也能够更加全面有效的评估产品，而厂商也能够拿到更加细致的反馈。

尽管开源带来了诸多好处，但不得不说，这些好处往往体现在项目前期，而非后期。不少人所说的“开源能够带来病毒式传播“，其实指的是前期项目知名度，而非后期全面商业化变现。在前期，创业公司需要做的是寻找到一种低成本的方式获得更多人的关注，而开源正是一种很好的低成本宣传手段。我们看到，不少工程师都非常热衷于开源，会主动寻找开源产品、尝试产品、研究代码、或者在某些社群中分享。这些都为开源项目的普及提供了良好的环境。

然而，到后期，商业化变现是否能够实现”病毒式传播“，与是否开源其实没有太大关联度。我们看过无数产品后不难发现，实现商业化变现的病毒式传播的关键在于客户的口碑营销（word-of-mouth marketing），而口碑营销并不依赖于开源。举例来说，通信软件 Slack、Zoom 等并非开源产品，但他们通过搭建人与人之间的日常沟通平台实现了口碑营销；协作软件 Figma 也并非开源产品，但他们通过允许创作者之间交互实现了口碑营销；数据库产品 Snowflake 也并不开源，但是他们通过卓越的易用性在工程师圈子内形成了良好的口碑，从而实现了快速增长。对于这些非开源产品来说，早期销售团队的巨大努力为产品的商业化成功奠定了坚实的基石。这点毋庸置疑。

RisingWave 目前正处在需要实现超线性增长的阶段。开源的重要性不言而喻。但这并不意味着开源是唯一。除了产品本身需要保持高质量之外，高质量的内容创作与真诚的用户沟通 也是实现超线性增长的不可或缺的支柱。如果要问我作为 CEO，在 2023 年花费时间最多的事情是什么，那其实就是这两项。

竞争篇

关于 RisingWave 与 Flink 的性能讨论

RisingWave 是一个为流计算所设计的数据库。提到流计算，不得不提 Apache Flink 这一知名开源项目。RisingWave 被很多人知道，除了是因为我们不断发表高质量技术文章之外，很重要的一件事情是与阿里 Flink 团队的朋友们关于 RisingWave 与 Flink 性能对比的讨论。这事因我而起，我就在这里与大家毫无保留的分享事情的来龙去脉。

RisingWave 自始至终的定位一直是流处理数据库，而非流计算引擎，因此从本质上来讲，与 Flink 有竞争，但并非纯粹替代关系。实际上，在创立之初，不管是对内还是对外，我也很少去提 Flink。那为什么会开始提 Flink 呢？原因在于，“流处理数据库”这个词在当时还是太小众，教育用户会耗费我们巨量的时间。而不少潜在用户听完我们的推销之后，往往会去主动提及 Flink，并希望理解 RisingWave 与 Flink 的区别。对于做产品，”你认为你是什么不重要，别人认为你是什么才是最重要的“ (it doesn’t matter what you think of yourself; it only matters what others think of you)。既然用户都把 RisingWave 当作 Flink 的竞品，那为什么我们不干脆直接在宣传上直接把自己当成 Flink 竞品呢？我们的确也是这么做了，而事实也证明是奏效的。我认为，在早期（或者也许可能是在任何时期），千万不要幻想着教育用户，而是站在用户的立场上，为用户解决问题。既然 RisingWave 与 Flink 的对比是用户反复提出的问题，那我们自然需要帮用户理解。顺着这一思路，我们也在早期让用户将 RisingWave 当作 Flink 在测试环境下的替代品，正如我在本文前面提到的。

我们再来谈谈 RisingWave 与 Flink 的性能对比一事。如果从早期便开始关注 RisingWave 的朋友们应该知道，RisingWave 使用的口号一直是“让流计算平民化”，也就是大幅降低流计算门槛，提升流计算性价比。我作为 Redshift 工程师背景、拥有数据库方向 PhD 学位的创始人，自然非常明白 性能对于用户来讲从来不是首要考虑项。那我们为什么还提性能？原因还是同样的：因为用户希望看到。我相信不少工程师背景的用户都认同”性能并非最重要的“这一事实，但实际上，公司的工程团队在向上级领导层提议引入一个产品时，几乎肯定需要向领导呈现不同产品间的对比：领导永远不希望看到只有一个可选项。而为了做对比，所谓”更易用”几乎很难打动领导，尤其是在经济下行周期中。领导需要看到一个可量化的指标，而 最简单的可被量化的指标便是性能。我们最早做的性能报告便是为了几个大企业中的工程团队向上级汇报所准备的。而我们当时公开发表性能报告也并没有预料到后续发生的一些事情。

与阿里 Flink 团队的小伙伴关于性能对比的讨论完全是意料之外。当阿里 Flink 小伙伴公开对我们的报告作出反驳时，我当时想的只是：这是一个千载难逢的机会。实际上，如果大家回顾之前任何两个产品在网络上的公开对比，如 Snowflake 与 Databricks，如 Iceberg 与 Hudi，就不难发现，公众在短期内可能对结果产生浓厚兴趣，但在长期来讲，没有人还记得结果，只记得了这两个产品进行过对比。因此，这场 RisingWave 与 Flink 关于性能的讨论的结局，从一开始就已经确定了，那就是 强化了公众对两个产品关联度的印象。至于性能到底如何，只不过是一个短期的技术性讨论罢了。“All you need is attention”。这是一个云厂商高管在这事情发生之后对我说的话。是的，all I get is attention。

当然，进行公开讨论，也是有后果的。后果其实在一开始也是可以被预估的，那就是，被动了利益蛋糕的人或多或少会产生不满。正如我的一位 advisor 所说的，我们毕竟是 “poke the bear”，面对的是机遇与挑战，需要做好周全的准备。在此之后，我的确感受到了个别个人（并非阿里 Flink 的朋友）对我产生的误解甚至是敌意，并在一些场合做出了一些不友善的举动。我对此全盘接受。平心而论，任何人从潜意识上都会去保护自己的利益。当自己的利益被他人所触碰时，几乎不可避免的会产生抵触情绪。而这一情绪所导致的举动因人而异。我们没有办法去改变他人，只能从他人角度理解他人，并为自己的行为负责。

我在这里不得不去赞扬阿里 Flink 团队小伙伴的专业素养。我们不提性能对比结果，但从性能报告本身来讲，是具有足够专业度的。我们也通过性能对比，更加全面的了解了 Flink，为 RisingWave 自身进一步性能提升提供了非常好的参考。与此同时，不管是我个人，还是 RisingWave 团队的工程师们，都与阿里 Flink 团队的小伙伴们保持着非常好的关系，并不断探究在工程、市场等方面合作的可能性。我在这里真诚感谢阿里 Flink 小伙伴们的付出。

RisingWave 的定位与竞争

随着 RisingWave 的批量落地与商业化推进，我们也不断调整着 RisingWave 的宣传口径。如今，我们已经开始更加强化 RisingWave 的数据库定位，而非单纯的流计算。尽管我们并不期望于能够充分教育用户、教育市场，但我们期望用户功能清晰的理解到 RisingWave 的价值所在。

如今，我们已经清晰的勾勒出了 RisingWave 的两大特性，即大幅简化架构，以及大幅提升性价比。并不断打磨这两大特性，构建更高的技术壁垒。

RisingWave 相比于传统流计算方案可以大幅简化架构。

流计算技术已经发展了二十余年。然而，流计算的商业化仍然处于非常早期。我是非常反对流计算的厂商在如此早期阶段进行商业层面内卷化竞争的。毕竟，在这一时期竞争，消耗的都是大家宝贵的工程、产品、宣传带宽，对大家一起做大蛋糕毫无益处。在这一阶段，流计算的真正竞争对手是批计算。我们可以非常清楚的看到，传统批计算公司，如 Snowflake、Databricks 等，已经开始逐步向流计算领域进军。他们才是所有流计算公司的共同的、最强有力的竞争对手。这也是为什么我期望尽可能多的与流计算公司或团队开展合作，共同教育市场。

当然，我是非常支持技术层面的竞争的。无论是易用性还是性能，在技术层面进行竞争，都能够让大家的产品更加成熟、更好满足用户需求。对 RisingWave 来说，我们看到了 Flink 在功能全面性方面的强大实力，因此在不断补全自己的能力；对于 Flink 来说，Flink 的存算一体、更高频 checkpoint 等新的发展方向，也说不定能够参考 RisingWave 现有的设计。

商业化篇

市场大环境

众所周知，2023 年对于世界各国来说，都是相对艰难的。刚刚走过三年的疫情，随着美联储的加息，各大公司都进行了大规模裁员，整个市场都是非常焦虑的。

2023 年可谓是降本之年。在我与不少公司的沟通中，都能体会到企业对降本的渴望。然而，我并不觉得降低成本这件事情会对像 RisingWave 这样的新兴企业会造成很大影响，相反可能会带来不少机会。这是因为，当企业考虑降低成本时，他们一定首先考虑减少开销最高的产品的用量，例如 Snowflake、Datadog 等。当减少用量仍然不能满足企业需求时，企业就会开始考虑替换。而当企业考虑替换时，便是新兴产品的机会了。

当然，降本并不代表着总是对新兴产品有利。事实上，当企业考虑降本时，往往会暂停掉一切探索性业务，如探索更实时的计算、更新颖的设计等等。毕竟，当经济下行时，企业的领导层会变得更加保守，更加倾向于将现有资源集中在与营收挂钩的业务上，而非重构自己的底层基础设施。

2023 年还有一个大趋势不得不提，那就是大模型。大模型的极速崛起实际上是对数据库类的软件稍微有一定冲击。毕竟，大模型是属于新鲜事物，任何人都会期望通过新鲜事物获益。当一家公司有资源投入在探索型业务上时，他们可能很显然更倾向于投向大模型这种潮流事物上。

不少朋友向我提出，RisingWave 是否会考虑蹭 AI 的热度。我是明确反对的。RisingWave 是一家数据公司，不是一家 AI 公司。我们只会帮助 AI 公司实现数据实时化（例如在线特征工程等），但不会直接转型触碰 AI。这有至少两方面的原因。首先，我一直坚持专业的人做专业的事。我是数据库专业的，对 AI 的理解仅仅是皮毛，无法真正理解 AI 用户的需求。其次，一家公司（尤其在早期阶段）开始做转型的时候，往往意味着他们对之前业务的否定。而我对 RisingWave 的前景充满信心，并认为业务上还有足够大的发展空间，没有必要通过 AI 的热度来寻找更多空间。

当然，我并不是一个固步自封的人。实际上，我会不断观望 AI 领域的发展趋势。尽管我的专业技能不足以支撑我直接入场 AI，但我还是会反复思考 AI 与 RisingWave 结合的可能性，在时机成熟时，作出改变。

大一统系统：理想与现实

RisingWave 是一个流计算系统。在过去的三年间，我被反复问及了一个问题：RisingWave 是否可以做“流批一体”。有意思的是，提到这一问题的，几乎无一例外都是国内的小伙伴。

首先我先说结论：RisingWave 的确在向“流批一体”迈进。有兴趣的小伙伴们可以关注 RisingWave 公众号即将发布的文章。

然后我再来说我的观点：我认为，无论是“流批一体”，还是“大一统”，本质都不是技术问题，而是商业问题。从技术层面，只要给无限长的时间（当然这非常理想化），总是能够作出一个各个方面都打磨的非常完美的系统。然而，在商业层面，由于各个国家的市场情况不同，导致了发展方向不同。在这章，我们不谈技术，但从商业层面谈一下我对“流批一体”或者“大一统”系统的看法。

从用户视角来看，用户一定是期望使用更加简洁的解决方案解决自身遇到的所有问题。然而，不同国家的用户倾向于接受不同的路线。简单来说，中国的用户更加倾向于期待一个全都能做的大一统系统，而美国的用户更加倾向于期待各个不同系统能够无缝对接起来组装成一套方案。我们可以举出无数多的例子来去证明这一观点。例如，中国用户喜爱的沟通软件为飞书、钉钉等大一统系统，而美国用户喜爱的方式是 Slack 加上 Zoom 加上 Notion 这样的组合。

为什么会出现这样的区别？我相信，本质原因还是在于两国 用户付费能力存在差异，以及 市场的发展阶段存在差异。

相比于美国，中国的用户付费能力相对较弱，导致厂商比较难以通过单纯一个垂直领域发展壮大自己。为了更好的生存下去，中国的厂商不得不向广度扩展，通过打造更加全面的产品实现更大化利益。而对于美国的用户来说，付费能力较强，他们愿意花费更多价格购买组合产品来满足自己各个方面的需求。正因如此，美国的厂商可以尽可能的往深度发展，在单一垂直类别打造极高壁垒，并在广度方面与其他垂类厂商合作，为用户提供统一的解决方案。

从市场角度来说，美国的云计算市场还是领先于全球的。在这一市场中，批计算系统如 Snowflake 等都已经非常成熟，想要在批计算领域击败 Snowflake 在短期内几无可能。与其与成熟产品短兵相接，不如避其锋芒，选择新的赛道进行创新。这也导致了为什么美国的产品更多的偏向于优先发展细分赛道，而不是上来遍铺开来做大一统系统。而在中国市场，中国并不存在 Snowflake 这样的巨头，在各个赛道上均较为空白。与其将这些机会都拱手让于别人，还不如自己全盘通吃。

当然了，这两种发展模式对其生态长久来讲会造成几乎不可逆的影响。在这方面我们便不展开描述，不过欢迎大家讨论。

我的个人感悟

最后，我再来聊聊我自己的个人感悟。回首过去的一年，我学会并坚持的原则，便是“be myself”，做真实的自己。简单来说，便是表达自己真实的观点与看法。如果说创业公司如何打动用户，那我私以为就是使用真诚。绝大多数消费者都是理性的：他们不会对创业公司有不切实际的幻想，他们也不会因为一句广告语或者一次推销就去购买某个产品。尽管创业公司的产品可以在各个方面都号称远胜于大公司售卖的老牌产品，但有一个方面可以让这些老牌产品轻松打败创业公司的产品，那就是“信任”。

在我过去三年与各类公司的对话中，我时常听到以下这些：“我们觉得某某大公司更加可靠，所以选择某某产品”；“大家都选某某产品，所以我们也选”；“某某产品太新了，我们不选“。所有这些，归根结底都是围绕着”信任“二字。不管对于什么类型产品来说，信任比其他任何特性都重要。大银行一般都会选择采购 Oracle 的数据库，因为 Oracle 与大银行们已经构建了十几年甚至几十年的互信关系；消费者一般都会选择购买老字号产品，也是因为这些产品在过去的数十年间在消费者心中构筑了可靠的形象。

构筑信任的最重要的因素之一便是时间。时间越久，信任感越长。而时间正是创业公司所缺失的。那么在短时间内，创业公司如何与消费者构筑信任？我相信是靠真诚。在过去的很长一段时间里，我都会坚持自己写公众号文章、自己在社交媒体上发信息、自己在社区里回复用户问题、自己在线下拜访客户，等等。我所做的一切，一方面是为了我能够更好的理解用户，另一方面便是为了让用户更好的理解我。我希望用户知道，他们在使用 RisingWave 的时候，面对的不只是一个开源项目，而是一个愿意帮用户及时处理问题、分享最佳实践、共同打造更优秀产品的团队。还是那句大家常听到的话：客户成功，就是我们的成功。

有一个问题我也时常在想：向用户推销产品的时候，我们应该谈论产品的不足吗？我们不难发现，几乎没有产品（尤其是成熟产品），会说自己的缺点。但是，所有人都应该知道，世界上没有完美的产品。尤其在计算机领域，无论是硬件还是软件，无论是数据库还是操作系统，实际上都是在不同的优化方向之间做取舍。当然我完全理解为什么大多数产品不愿提及自己的缺点。毕竟，大家都怕提了缺点之后劝退用户，砸了自己的招牌。我与大家一样，我自己也怕。但我认为，还是有必要向用户说清楚情况，让用户对产品有更合理的期待。我目前的做法是，当被用户问到与某某产品对比时，我总是会跟用户说清楚各个产品的优化方向，或者说清楚不同产品间所做的取舍。我的理念是，对于创业公司来说，不应该一味的迎合用户，而是也要选择用户。当然，我们并不是以用户的体量、付费能力来做选择，而是永远选择讲道理的（reasonable）用户。讲道理的用户自然能够对产品设置更为合理的期望，也能够理解不同产品之间取舍的存在。当一个用户为产品设置了不合理的期望时，用户与厂商之间的合作很可能会耗费过多的精力，对双方都是一种折磨。

当然有人会说，做真实的自己可能会遭来一些人的反感；做人应该圆滑一些，“见人说人话，见鬼说鬼话”。我只能部分认同。

谁会去反感一个真实的人？我相信，大多数情况下是与自己有观念或利益冲突的人。一个潜在用户不认同我的产品、我的理念，自然我说什么都会被其嗤之以鼻；一个友商的员工自认为我在与其竞争，自然会充满敌意的理解我说的每一句话。我尽管希望我个人以及我们所做的产品能够被更多的人所喜爱，但不意味着我们需要无条件的迎合所有人。我们应该还是需要做自己，让更多的人认同自己的观点，被认同自己的观点的人所喜爱。

我认为所谓为人圆滑，指的是换位思考，站在对方的立场上从对方角度说话。由于背景、性格等各方面的不同，每个人都可能对事物都有自己独特看法，并用自己的方式与这个世界交互。与其一味从自己角度表达观点（“我要卖货我要卖货！”），不如多从他人角度考虑如何最大化利益（“我卖的货能够帮助别人解决什么问题？”）。

当然了，这个世界是复杂的，我没有意图、也没有办法去说服所有人。但我还是希望能够独立思考，做真实的自己。

结语

三年到底有多长？瑞幸咖啡作为全球最快 IPO 的公司，从创立到上市使用了 17 个月；趣头条使用了 2 年 3 个月；拼多多使用了 2 年 10 个月。三年对于这些公司来说，足以从无到有，从有到上市。然而，对于一家数据库公司来说，3 年只是算一个起步：Snowflake，这家史上市值最高的 SaaS 公司，于 2012 年 7 月成立，到 2015 年才推出了云上数仓（也就是今天大家熟知的产品），而在 2014 年获得了种子用户。

对于 RisingWave 的 2024 年，我并没有什么过多的想法。对于我来说，我所追寻的并不是什么星辰大海，而是仅仅期待脚踏实地将每一个生产案例做好做精，并按照既定路线实现商业化增长方面的目标。在新的一年里，我当然也希望结交更多的朋友，看到更大的世界，更加充实的过好每一天。在这里也祝各位新年快乐，前途似锦！

作者简介

吴英骏，流数据库公司 RisingWave（risingwave.dev）创始人 &CEO。博士毕业于新加坡国立大学计算机系，为前 Amazon Redshift 工程师和前 IBM Research Almaden 研究员。常年担任数据库三大顶会 SIGMOD/VLDB/ICDE 的评审委员会成员。技术交流可以关注公众号“RisingWave 中文开源社区”或者添加微信“risingwave_assistant”。

活动推荐

12.28 （周四）20:00，专属于技术人的年度复盘来了！