不缺好数据库内核，缺能用好数据库的DBA
最近知乎上的老问题 “postgresql也很强大，为何在中国大陆，mysql成为主流，postgresql屈居二线呢？” 冒出来几个新答案
有朋友转给我，问我怎么看。
我觉得说的挺好的，老冯的看法是，最狭义上的 PostgreSQL 内核并不是一个 “产品”，而是一个 “项目”。直接裸使用 PostgreSQL 内核本身，其实是有不少问题与坑的。而这些问题与坑，就是 DBA，RDS，发行版，以及商业产品要去解决的。
如果你用 Linux 操作系统就很好理解，没什么人会直接去使用 Linux 裸内核的。大家使用的都是 RedHat，Debian，Ubuntu 这样的操作系统发行版。一个 Linux Kernel 才几 MB，但是一个操作系统发行版的软件包加一块儿可以塞进几张 DVD （十几GB），你还需要 systemd, 定时任务，时间同步，DNS解析，日志等各种组件才能将这个裸 Linux Kernel 包装成一个实用的操作系统
例如，PostgreSQL 生态里有着 1000+ 扩展插件。像 PostGIS 这样的扩展代码（170万行）甚至比 PostgreSQL 本身（100万行）还要多。有着好几本专著和自己的子社区。更别提最近蓬勃发展的向量/DuckDB/Tantivy扩展缝合大赛了。如果你什么 PG 扩展都没用过，那我可以肯定的判断你错过了 PG 生态的精髓。
在运维与服务搭建上也同理，如果只是 yum install postgresql systemctl start 这样安装 PG 裸内核，那属实连 门都没有入。一套生产级，企业级的 PostgreSQL 数据库服务一定是成体系的。围绕内核通过架构/扩展来解决各种裸内核的问题。例如：
- 高连接数性能下降，那么就需要 pgbouncer 链接池
- 内核本身不能高可用，但是 patroni 可以提供高可用
- 备份与时间点恢复，需要用到 pgbackrest
- 采集监控指标，需要用到 pg_exporter
- XID 回卷和磁盘写满，那么就一定要有监控告警
- 表有膨胀，那么用于在线治理膨胀的
pg_repack就属于必选扩展
上面的每一个问题，都会有几种不同的备选组件，堪称是 FOSS 展销会大舞台，那么哪一个是最好的？有什么坑没有。
对于一个可靠的 PG 服务而言，这些生态组件的使用经验甚至比 PostgreSQL 内核经验更重要。而这种将开源零件组装为企业级服务的 “最佳实践” 的经验是 极为极为极为稀缺的。
因此，另一个值得一提的答案来自 @kimmking ：“其实国内 PG 没有普及的关键在于严重缺少 DBA 。”
早些年，国内互联网场景用 PostgreSQL 的就是探探和去哪儿，金融领域就是平安银行。能称得上“复杂/规模” 也就这几个，而这样一个公司能有几个 DBA 坑位？而这里的 DBA 又有多少是经过大故障洗礼，或者愿意精益求精深挖研究下去的？高级的 DBA 是甲方用真金白银的故障砸出来的。国内 PG 圈子很小，像这种在内核层面分析问题的 PG DBA 不客气地说两只手就能数出来了。
我认为对于 PostgreSQL 来说， DBA 这个 Title 其实很有误导性，因为 PostgreSQL 只是一个 “发动机” 零件，而不像 Oracle 那种直接买的 “整车”。Oracle DBA 是对照手册进行操作的 “司机”，属于数据库解决方案的一部分。而 PostgreSQL “DBA” 实际上是要自己去设计解决方案，用开源零件攒车的架构师。这也是为什么堪用 PG DBA 如此少的原因 —— 会造车的工程师要比会开车的司机稀缺太多了。
但是有一个办法可以解决这个问题，就是直接用已经经过长期大规模实战考验的体系化攒车方案（甚至是自动驾驶方案），而这也是我做 Pigsty 的原因。让 PostgreSQL 用户跳过 “攒车” 阶段，直接开车即走，甚至连司机都不一定需要了。
DBA会被云淘汰吗？驳《再论为什么你不应该招DBA》云数据库是不是智商税DBA不是数据库的用户，开发者才是！数据库的“萝卜快跑”时刻已到，DBA 请下车\