PG 30 周年直播, 第八期

PG 过去赢在哪儿，边界又在哪儿？PG 是哪类场景首选，又该在什么场景下让位？

赢在社区治理, 始终坚持“企业级 OLTP 产品质量 + 扩展性”. 更通俗的说是“数据库底盘稳定性+扩展接口的丰富度”. 把底盘稳定性和扩展接口丰富度留给社区, 把扩展的实现交给生态. 可以说 PG 社区把开源生态玩出了花, 看看 PG 有上千个生态扩展就知道.

边界, PG 是中型既要又要还要的场景首选. 当用户是单一功能极致场景时, 选择专业领域数据库. 例如“属性图、向量、时序、搜索、地理信息、文档”每个领域都有专业的数据库.

但是也必须提一下, 到底中型是多大数据量、多大并发? 这个边界根线跟着技术进步在上移.

板块二 · 谁在分食 PG

你最担心 PG 被谁分食？

很多人可能担心 PG 被“属性图、向量、时序、搜索、地理信息”专业数据库分食, 但我并不认为, 因为这些专业数据库抢的就是单一功能场景需要极致体验的用户, 这些用户最初可能因为 PG 的扩展选择了 PG , 当他们在这个扩展无法应付时, 自然会走向专业数据库, 而且 PG 主打的也不是每个场景都能做到极致, 它主打的前面已经说了: “中型规模, 企业级 OLTP 产品质量 + 扩展性” . 发展某个单一场景显然违背了 PG 社区的初衷.

我更担心的是云厂商. 如果只想着从 PG 开源社区吸血, 而不回馈社区, 迟早 PG 的发展将停歇. 你想一个问题, 在云厂商大面积吸血之前, PG 社区的主力研发来自哪里? PG 商业版分发商、PG 服务提供商、PG 大型最终用户. 而这些贡献者因云厂商吸血很难过日子, 未来会逐渐无力持续贡献 PG , 最终导致 PG 贡献者断层.

云厂商不仅对 PG 有影响, 对其他开源数据库影响是一样的, 因为背后逻辑是一样的.

如果 PG 没了, 对云厂商来说也不是好事, 因为开源蓄水池没了, 你得重新教育用户、你得100%投入研发(缺少了社区的研发力量分摊你的投入)、你得重新为自研产品做市场拓展. 当然, 好处就是锁定用户, 但用户会用脚投票, 他们会优先选择其他云厂商兼容开源的产品.

说到这里, 我也必须要承认一件事, 那就是云服务形态也许是不可逆的趋势, 所以 PG 被云厂商的服务分食不可逆. 那就只能寄希望于 PG 社区尽早的在云厂商侧做工作, 共建 PG 开发者社区, 目前已经观察到国外已经有一些云厂商在重度参与 PG 开发者社区了.

板块三 · 历史包袱

PG 30 年背着哪些历史包袱？

坚持企业级的产品质量, 既是优点也是包袱. 社区总想向下兼容, 总想完美的方案, 特别是存储层面的向下兼容, 或有平滑升级的方案.

例如: 1、32位 xid 带来的xid回卷问题和freeze开销, 2、HEAP 追加更新的设计带来的垃圾回收、膨胀问题.

总是差了临门一脚, 不是方案不够完美, 就是向下兼容性不够好, 甚至一个方案探讨了十几年, 人生能有几个十几年, 可能当时提出方案的人都已经不在当时的岗位了.

板块四 · 局限与赌约

站在 30 年肩膀上往后看 10 年 —— PG 最需要承认的一件事是什么？最该守住的又是什么？

承认 PG 有边界, PG 是中型既要又要还要的场景首选, 但当用户是单一功能极致场景时, 果断选择专业领域(例如“属性图、向量、时序、搜索、地理信息、文档”)数据库.

PG 最该守住的是它的初心: “坚持企业级 OLTP 产品质量 + 扩展性”. 任何场景都有 28 法则, 80% 的可能是长尾场景, 这些用户体量中下等, 这些用户既能磨练产品, 又能帮你传播产品, 是 PG 主要服务的用户. 而另外的 20% 也不是突然就变成那 20% 的, 他们也是从小长到大的, 这些用户未来可能会转向云厂商提供的高端 PG 兼容产品, 或者转向专业领域产品. 所以 PG 已经在用户演进的必经之路上(说得直白一点, 不管什么垂直场景, 用户第一个想到的就是 PG, 这就成了. 重要的标签: 企业级、扩展性、中级规模首选.), 未来不管什么场景火起来, PG 都能通过扩展快速支持该场景, 所以 PG 只要守住初心, 就能屹立不倒.

你希望 10 年后的 PG，和今天最大的不同是什么？

我希望 10 年后的 PG 社区的初心不变, 依然“坚持企业级 OLTP 产品质量 + 扩展性”, 同时希望核心 committer 的结构依然健壮, 但是更多的云厂商、PG 衍生数据库厂商成为核心贡献者.(必须提一下国内的 IvorySQL 已经持续给 PG 社区贡献多年,贡献者当中肯定还有我未提及的其他厂商，欢迎留言补充)

收尾

PG 是开源世界里最值得我们认真对待的关系型数据库。