附经纬创投公众号融资新闻

Bytebase完成300万美元天使轮融资 |【经纬低调新闻】

从1月初写下第一行代码，到7月初开源0.1版本，再迭代到如今的0.8.1版本，一路走来获得了不少小伙伴的关注和鼓励。所以今天也和大家分享一下 Bytebase 刚完成了由经纬创投独家投资的三百万美金天使轮融资，同时 PingCAP 的 co-founder/CTO 黄东旭也作为个人天使参与了本轮融资。借此机会在这里我们更想分享一些产品的思考，接下来的发展规划，以及融资背后的一些故事。

先再简单介绍一下 Bytebase 的背景，它是一款聚焦在 Database schema change and version control 的工具。它主打的是在应用研发过程中变更数据库结构 (schema) 的场景，主要面向的人群是研发工程师和 DBA 。既然 Bytebase 是一款数据库领域的工具，所以先来谈一下我们对于数据库行业的发展认知。

数据库行业发展的三个阶段

1970 ~ 2010 Cornerstone

从关系模型的提出，SQL 以及 System R 系统的发明，再到以 Oracle, SQL Server 为代表的商业数据库，以及 MySQL/PostgreSQL/SQLite 为代表的开源数据库的流行，SQL 以及关系型数据库通过无数的实践成为了软件开发的基石，但凡是有存储数据需求的软件绝大多数都会使用关系型数据库来读写数据。在这个阶段，数据库解决的问题是让应用可以通过一种接口 (SQL) 来完成对于数据的增删改查。

2010 ~ 2020 Web-scale

2010年之后随着互联网的爆发，对于数据库增删改查的压力暴增，导致之前所有的数据库系统都无法支撑，行业出现了 MongoDB 这样的 NoSQL 方案，基于 MySQL, PostgreSQL 再配合中间件的分布式方案，以及自带分布式能力的 NewSQL 方案。在这个阶段，数据库领域解决的新问题是去支撑起超大规模的互联网服务。

2020 ~ Beyond performance

之前的两个阶段都是随着软件业及互联网发展，基本由业务场景出发，驱动数据库从解决简单数据的增删改查，逐步发展到解决巨量数据的增删改查。这一路能支撑起业务的高速发展已实属不易，虽然也不免留下一地鸡毛，尤其是运维侧的一堆烂摊子。

当数据库体系越来越复杂，运维复杂度越来越高，整个行业也开始寻找下一代的架构方案，去更加高效优雅地和数据库打交道。

比如说公司意识到业务并不需要一套 OLTP, 一套 OLAP，所以就出现了 HTAP 的方案，这样可以避免维护两套系统，也省去了同步数据的工作。还比如近两年挺火的自治 (Autonomous) 数据库概念，通过规则引擎和机器学习来减轻运维诊断数据库的负担。更直观的例子可以看各大云厂，以及各家数据库厂商，他们现在都是靠提供用户友好的云平台作为核心增长引擎，Snowflake，MongoDB Atlas 都是其中典型的代表。

引擎和工具的关系

数据库最核心的部分我们称之为内核或者引擎，就像汽车引擎一样，在数据库发展的阶段1和2，解决的是引擎如何跑起来，以及如何跑得快又不爆缸的问题。这两个阶段主要的挑战在于引擎本身的研发。而到了阶段3，也就是当下的这个阶段，大家开始注重起了驾驶体验，这个时候除了引擎之外，工具也有了发挥的空间。就像各家云平台，其实也就是围绕数据库引擎构建一套工具集，形成一套完整的解决方案 (我们的创始团队就曾帮助构建了 Google 云数据库服务)。

现在数据库从引擎唱独角戏走到了引擎和工具相辅相成的阶段。当然工具还是需要围绕引擎来构建的，许多时候引擎本身不提供能力的话，工具可能也无能为力，或者要花很大的功夫曲线救国。在做 Bytebase 的过程中，我们其实也意识到，我们做的有些功能比如 schema 版本管理，如果引擎本身就原生支持的话，工具把它再进一步包装的产品化方案会简单和完备不少。

我们也思考过如果今天要再从头构建一个新的数据库，该如何和已有的200+数据库形成差异化呢？

光讲性能是不够的，我们更会考虑如何优化开发者体验。

诸如研发流程上的创建数据分支，Schema 变更和版本管理，备份恢复，数据脱敏，运维场景下的监控，日志，压测，诊断，巡检，多租户支持，凡此种种。当前这一代的主流数据库其实在设计之初并没有太关注到这些场景，主要还是聚焦在核心引擎的打造，而相对忽略了整体驾驶体验的顶层设计。

所以，要不就做这么一个数据库？

Bytebase的切入点

Bytebase 并没有去选择从头开始自研数据库来解决开发者体验的问题，而是想办法通过工具层的解决方案去弥补引擎层的不足。尤其是要去补位那些已经被广泛应用，但是工具体系还不成熟的数据库系统，比如开源的 MySQL, PostgreSQL。而诸如 Oracle，SQL Server 这样的商业化数据库，他们本身的工具体系已经相当成熟，所以不是 Bytebase 要去支持的对象。我们选择这条路径一是因为我们相信，数据库很难一夜之间切换到新的系统 (因为数据的粘性)，大部分用户希望的还是帮助他们驾驭当前的数据库系统。同时这条路径也最能发挥我们团队的优势，毕竟我们之前在国内外数据库体量数一数二的公司 (Google 和蚂蚁集团) 都在做类似的事情。

Bytebase接下来的计划

Database schema change 是研发链路上的必经环节，但像MySQL, PostgreSQL 这些都流行了20多年，业界依然也没有出现一个不错的方案，可见光做好这点就是很不容易的。作为一家初创公司，中短期我们还是会集中精力，把 database schema change and version control for teams 这个单点做到业界最好，当然我们会去支持多种数据库类型，只要是业界流行又缺乏良好工具体系支持的数据库系统都在我们的射程范围内。我们当前的产品已经支持了MySQL，PostgreSQL，TiDB，Snowflake 和 ClickHouse。

不过 schema change 的问题其实是我们想解决的更泛化问题下的一个具体场景，我们其实是想通过解决 schema change 的问题构建起一套基础设施，帮助我们去解决之后的一个更加宏大的命题，至于具体这是一个什么命题，先卖个关子，等我们解决好当下的问题后再和大家分享吧。

接下来我们也有推出商业付费版的计划，短短的时间可以获得上千的 GitHub星星，这是社区用户对于我们的鼓励。但同时我们相信验证产品最好的方式还是来自于用户的支票。

选择融资

选择融资的原因还是为了能够大幅提升产品的迭代速度。Bytebase 至今一直只有一名全职研发 (不过下周就会迎来2位全职同学)，虽然也能把东西一点点搭建出来，但随着产品的推广，需要处理的事情也越来越多。而作为一个工具类产品，又是想做到业界顶尖，还是需要前后端，设计，产品，交互各方面的专家技能点，单打独斗是有点力不从心了。

而我们再看这条赛道的潜力，其实研发链路上的坑基本都已经占完了，Bytebase 切入的应该是仅存的几个空档之一。而只要产品能在研发链路上占住一个坑位，服务好几个核心角色，那也还是可以满足 VC 期望的投资回报。要能占住坑位，一个是产品要好，一个是要快，不然坑就可能被别人占了；）总之我们还是自认为找到了一条长长的坡道，而融资可以帮我们快速把雪球滚大，有资金可以来招募产品研发方面我们需要的人才。

这次 Bytebase 有幸是和经纬合作，这里面有偶然的因素。比如说我们是通过一个中间人开始了接触，而这位中间人和 Bytebase 创始人的结识又是因为一只龙猫。

牵线了几百万美金投资的龙猫

当然合作的达成，更多的还是源于对于彼此专业度，做事风格的认可。尤其对于 Bytebase 来说，作为一家中国公司涉足开发者工具领域，从 Day 1 面向的就是全球市场，采用开源产品驱动的方式。这套打法在国内说不定也还是第一家，其实也是面临着不少争议和挑战的。而经纬的投资团队在很早期就投资了国内开源 Infra 赛道上不少的先驱公司，所以既可以和我们共情，又可以给我们带来许多的帮助。

此外 PingCAP 的 co-founder/CTO 黄东旭也以个人天使和 advisor 的身份加入了这轮融资，这也算是因缘巧合。一次线下聚会上东旭正好坐在了我们的旁边，于是我们就安利他试用一下 Bytebase，然后就看他照着文档用 docker 把我们的产品跑起来了。可能他没想到居然官网所宣传的5秒部署是真的，也就当场被收买了吧：）

我们正在招聘

合作的同伴决定了事情最终可以达到的高度。Bytebase 是一个一直相信个体可能性的团队，获得了第一笔融资，使得我们有能力可以去招募那些充满才华和可能性的个体，组建起一支小而精的团队。我们正在招募前后端工程师和全栈工程师，如果读者有兴趣的话，可以移步官网JD，社招/校招/实习生都欢迎，我们的面试题也是开源的。

这一年开源 Infra 方向受到越来越多的关注，产品驱动增长 (PLG) 的打法也逐渐在国内开始起势。Bytebase 至今获得的一点点认可，一方面是作为一款走 PLG 路线的开源 Infra 工具，很幸运地赶上了一个好时机，一方面也是因为我们之前一直在用心地做产品。所以接下来我们还是继续踏踏实实地打磨产品，毕竟 PLG 的核心还是那个 P(roduct)。

Back to build 🏗