Bytebase 支持 --pg 背后的故事

在‍ 1.0.4‍ 的发布里，Bytebase 添加了支持外部 PostgreSQL 来保存元数据的能力，通过在启动 Bytebase 时用 --pg 来指定。

背后的故事

之前 Bytebase 把自己的元数据库 从 SQLite 迁移到了 PostgreSQL，不过我们采用了内置 PostgreSQL 这个相对小众的做法。这样做的原因还是我们把元数据的保存方式看作了一个内部实现 (implementation detail) ，而不想暴露给用户。用户用的是 Bytebase 产品，为什么要关心底下是用什么方式存数据，还要多额外的一步去配置数据库呢？尤其是对于开发者体验 (Developer Experience) 来说，内置数据库的优势是明显的，开发者不需要配置任何额外的数据库依赖，直接就能把 Bytebase 跑起来了。

不过另一方面，社区里的用户还是希望可以提供配置外部 PostgreSQL 的方案：

这个需求也是合理的:

1. 首先这是业界主流的方式，符合用户习惯。
2. 可以使得 Bytebase 本身变得更加 serverless 化 (但给应用数据库的备份目前还是放在本地磁盘，需要改进这部分的功能才能做到彻底的 serverless / diskless)。

我们一开始也有点犹豫，到底要不要现在就支持。因为还有一点顾虑，是外部的 PostgreSQL 缺乏可控性，将来可能要去 debug 各种环境问题 (比如连不上外部数据库，用户权限问题诸如此类)。

在团队犹豫之间，是外部贡献者 @tison 直接推动了这个事情，发起了 PR feat: support to specify external pg instance as metadata storage。

看这个标题是直接把功能做完了，其实不然，这个 PR 只是吹响了进攻的号角，后面还有各种来来回回，涉及一些内部的改造。终于经过各方努力，现在用户看到的，就是我们提供了一个 --pg 的参数，可以让用户在启动 Bytebase 时指定外部的 PostgreSQL 数据库，当然这个在实现上有许多要考虑的点:

比如在参数设计上:

1. 是用单独的 --port, --host, --username, --password，还是用一个参数。讨论后我们决定选择一个参数。
2. 参数的名字，是用更加通用的 --dsn (Data source name) ，还是用特定的 PostgreSQL 名字。因为我们相当笃定我们不会再换其他数据库了，所以决定选择后者。
3. PostgreSQL 的表示方法也有好多种，postgres, postgresql, pg。我们最后选了 --pg
4. 选了 --pg 后，参数的格式是怎么样的。最后我们选择了 postgresql://user:secret@host:port/dbname。这里主要决策的是最前面的 scheme 部分 ，因为这里也有好几个选项 postgres, postgresql, pg。是只支持一种，还是支持多种，还是干脆就不指定，每一种方案各自都有一些 tradeoff。

除了参数外，这个改动也涉及到内部的一系列重构，包括有一些还在进行中的。另外因为我们本来是内置了 PostgreSQL 数据库，PostgreSQL 本身的二进制文件还是有点大的。那如果用户使用的是外部 PostgreSQL，Bytebase 本身的二进制包是没有必要包括 PostgreSQL 这个二进制文件的，所以我们也还要进一步优化编译打包的流程，给用户单独提供不包含内置 PostgreSQL 的发布包。

后记

单独撰文记录一下，没记错的话，--pg 功能也是 Bytebase 自开源以来，正式对外发布的功能里，第一个由外部贡献者发起，推动，多少改变了我们产品优先级的核心功能点。

也可以看到，虽然暴露的是一个 --pg 参数，但背后也有许多的故事，从最一开始的 PR 到这次的发布，也过去了 20 多天，而且后续还有一些优化要做。

如果单纯从功能实现的角度来看，这是一个大致 1 天时间就能交付的功能点。但是要能干净地实现，经得起时间的考验，需要的功夫就远远不止了。