背景

在团队规模较小的时候，往往部门数量有限，沟通协作成本较低，暂时可以通过某几个人管理数据库的方式让独轮车跑起来。但是，随着团队规模的扩大，部门及人员数量的增长，部门间沟通协作成本增加，往往 20%的业务成为核心，80%的业务相对来说不那么重要，这时候往往会抓大放小。时间一长，问题就会涌现，变成出现事故解决流程，引入工具；而不是引入工具，解决流程，预防事故。

工具对比

市面上比较主流的工具有 Navicat,Yearning,DBeaver 等。各个组织引入和解决问题的方式有所区别，通过工具生成 SQL 变更文件，然后通过组织内部审批流进行；或者引入开源产品，公司搭建内部服务；又或者结合公司业务进行自研。

1. Navicat

这款客户端工具强大吗，确实强大。提供一系列丰富的功能，可视化的数据库设计和管理，导入和导出，数据库结构对比等等。但是，昂贵的价格，我个人觉得不够灵活的客户端，每个平台，每种数据库都需要单独下载一个客户端去进行管理，团队协作能力很弱，需要组织自行引入其他服务进行管理。

2. Yearning

这款开源产品在 SQL 审计方面做得比较不错，具备一定的组织协作能力，用户的权限管控较为完善。缺点也很明显，在云原生的今天，很多组织数据库上云，组织内部会有多种数据库共存，Yearning 仅支持 MySQL，相比于商业化的工具，它更多的是集中在 SQL 审计，其他方面的功能较弱，而且缺乏社区乃至商业上的技术和文档支持。

2. DBeaver

DBeaver 支持多种数据库，提供了丰富的数据库管理，可视化相关功能，社区支持十分强大，文档，插件相关资料很丰富，并且较为易用。但在 SQL 审计和团队协作方面比较不方便，安装文件较大，下载和安装时间较长，对资源较少的计算机，可能比较困扰。

介绍

到这里，我要说一下这段时间 ByteBase 使用下来的感受，这款工具是唯一被 CNCF Landscape 收录的 Database CI/CD 产品。技术背景和实力都挺靠谱的，具备海外和国内工作经验，视角更加全面，目前已经有很多公司在进行相关落地。在云原生的今天，传统的 DB 管理工具对云原生场景下很难提供更为全面的治理能力，对于开发人员来说，更希望像管理代码一样管理 SQL，这就引入了 ByteBase 的 GitOps 实践。传统 SQL 和代码是分离的，对于管理人员需要对他们进行两套不同的管理模式，这带来了一定的管理成本和出错可能性。更重要的是在团队协作方面的能力，是传统的管理工具所缺乏的，ByteBase 在这方面的能力十分优秀。

1. 部署

支持多种部署方式，Docker，K8s，Render 等

我推荐先通过 render 尝试部署使用，填写一个仓库地址，基本可以在几分钟之内搞定

部署完成后，能够看到主站和元数据库状态，如下

然后直接通过域名访问即可，整个流程十分丝滑

2. 团队协作

现在，让我们进行一次生产环境的表结构同步，我们想要在 employee 表中添加头像字段，可以自定义 SQL 审计插件，自动提交并通知审批人，SQL 审查可以设置不同的级别，如果违反了某些规则，可以禁用或者警告。

每个阶段清晰可见，当我们批准之后，可以去对应数据库查看变更记录，Schema 的对照十分清晰。

企业 IM 集成审批流也已经进入测试版，目前支持飞书，后续将支持更多三方 IM。

3. 版本管理

每次 Schema 变更后，都会生成对应的版本，可以查看版本历史记录，以及不同版本之间的比对。合并及冲突解决。我这里展示一个备份的流程，创建数据库审批完成之后，我们点击库表同步，这个时候选择源数据库和目标数据库，选择版本之后，预览即将进行的 Schema 变更。

接下来进行组织内部的审批流，等待批准后。

查看备份数据库数据及版本即可，能够看到相关的变更已执行。

总结

就我个人这段时间的使用感受，部署十分方便，并且十分贴合云原生的场景，支持多种数据库，团队协作方面十分出色，后续版本正式上线 IM 集成后，对很多企业来说如德芙般丝滑。是一款能够站在组织协同的角度出发，解决 DB 管理过程中不可多得的好工具，充分贯彻了 GitOps 这一理念，管理代码一样管理 SQL 变更，解决了开发人员这种协同的成本。希望在未来能够基于库表设计及 SQL 语句执行效率方面提供更多的助力。