我在 Docker Hub 上维护过一个镜像，名字叫 bilxio/postgresql-fat。
胖子。因为把能装的扩展都塞进去了——pg_http、各种 FDW、pg_vector，甚至试图集成 V8，让 PG 里可以跑 JavaScript。精简不是目标，方便才是。
这个镜像是为了一个具体的工程需求诞生的：在 AWS 上，用 PG 协调 60 个 Lambda 调用，从 S3 读数据，做并行聚合，对应用层暴露一张普通的视图。预算有限，RDS 规格升不了，ClickHouse 上不了，手边只有 PG、Lambda 和 S3。
这个方案跑起来了，而且跑得很好。
但让我真正开始想一个问题的，不是这个方案本身，而是它背后隐含的一件事：为什么每次在约束里找出路，底下永远是 PostgreSQL？
MySQL 也试过
在了解 PG 的 FDW 之前，我已经知道 MySQL 上有类似的尝试。
Memcached 插件是最有名的——把 Memcached 接入 MySQL 作为一种存储引擎，绕过 SQL 层直接读写内存缓存。Spider 引擎做分布式查询，TokuDB 做压缩存储。每一个都是某个具体问题的工程解法。
但这些扩展大多命运多舛。TokuDB 后来被 Percona 接手，维护缓慢，最终在 MySQL 8.0 里被移除。Spider 一直是边缘功能，用的人不多。Memcached 插件更是几乎销声匿迹。
PG 这边的扩展生态完全是另一番景象——pg_vector 成了 AI 时代向量搜索的标准答案，pg_http 还在被人用，timescaledb 把 PG 变成了时序数据库，PostGIS 把它变成了地理信息系统。这些扩展活得很好，还在生长。
为什么同样是"给数据库加功能"，两者的命运差这么多？
扩展机制的结构性差异
MySQL 的扩展点是存储引擎。这个接口天然有限——你可以替换底层的数据存储方式，但做不了存储以外的事。pg_http 那种"在 SQL 里发 HTTP 请求"的东西，在 MySQL 的插件体系里根本没有立足点。
PostgreSQL 的扩展点是整个数据库。
你可以加新的数据类型（jsonb、vector、地理坐标）；可以加新的索引方法（GIN、BRIN、自定义）；可以加新的函数和操作符；可以加 FDW 连接任意外部数据源；可以加后台进程做异步任务；可以加新的认证方式。CREATE EXTENSION 一行命令，一个新能力就进来了。
这个边界极宽的扩展机制，给了社区无限的发挥空间。你能想到的大多数需求，都能找到一个方向去实现，而不是被系统本身的设计挡在外面。
所以胖子镜像能装那么多东西——不是因为 PG 自己做了这些功能，而是因为它给了别人在上面建东西的空间。
Supabase 和 Neon 不是在绕开 PG
这是理解 DBaaS 格局的关键一句话。
Supabase 没有自己做一个数据库，它在 PG 上面建了一套产品——Row Level Security 变成了它的权限系统，pg_notify 变成了 Realtime 订阅，pg_vector 变成了 AI 向量搜索接口，pg_graphql 让你直接用 GraphQL 查数据库。Supabase 卖的是开发者体验，底下的引擎是 PG，从没变过。
Neon 做的事更激进——它把 PostgreSQL 的 WAL（Write-Ahead Log）流式复制机制改造成了存算分离架构，计算节点和存储节点分开，然后在这个基础上实现了 Branch：数据库可以像 Git 一样创建分支，每个分支是独立的副本，可以随意实验、随意销毁。
这个功能我第一次见，是 2009 年在一个 BI 团队的工位旁边惊鸿一瞥——他们自己做了一个内部工具，Web UI，一键切换数据库快照版本。那时候不知道它叫什么。Neon 2022 年把它做成了产品，卖给了所有人。
Supabase 和 Neon 能做这些，本质上是因为 PG 给了他们足够的空间。MySQL 的复制机制没有 WAL 这种可以被改造的层，MySQL 的扩展体系没有办法长出 pg_notify 这样的东西。他们选 PG，不是因为习惯，是因为在 PG 上面能建的东西，在 MySQL 上面建不了。
AWS 擅长基础设施，不擅长产品体验
Aurora PostgreSQL 是很强的产品——高可用、自动扩缩容、性能优秀。但开发者不一定选它。
因为 AWS 的界面太复杂了。VPC、Security Group、IAM、Parameter Group……光是让一个 RDS 实例能被外部访问，新手要踩好几个坑。Aurora 更复杂。
这不只是数据库的问题。AWS 推出 Lightsail，本质上是看着 DigitalOcean 和 Linode 用更简单的体验抢走了大量中小开发者，急了。Lightsail 就是 AWS 版的 Droplet——固定配置、固定价格、傻瓜界面。但夹在中间，补得不彻底，DigitalOcean 的社区文档更友好，真正有规模的团队还是会直接上 EC2。
Supabase 和 Neon 在数据库这个维度上做的事，比 Lightsail 在计算这个维度上做得彻底得多——它们把 PG 包装成了一个开发者从第一天就能上手的产品，Dashboard 清晰，Branch 直观，本地开发工具链完善。
AWS 和开源社区之间还有一条长期的张力线。Elasticsearch 那出闹剧是标志性事件——AWS 做了 OpenSearch，Elastic 被迫改许可证。PG 用的是 PostgreSQL License，比 MIT 还宽松，AWS 可以永远免费用，不会有那出戏。但 Supabase 和 Neon 靠的不是许可证保护，靠的是产品体验的护城河——AWS 就算想抄，也很难抄出那种开发者友好度。
另一种声音：云数据库是杀猪盘吗
说到 DBaaS，有一种截然不同的声音值得听。
批评者的核心算法很简单：同等规格的硬件，IDC 自建每年 3-4 万，AWS RDS 每年可以到 160 万以上，差了将近 50 倍。如果你的业务体量足够大、负载足够稳定，云数据库的弹性溢价根本不值这个价。有人算过，两三个 DBA 管几百台服务器，人力加硬件每年不到一千万；同等规模如果上云，费用至少五六千万起。
这个账在特定规模下是算得过来的。
批评者还指出了云数据库的另一个结构性问题：RDS 通常不给用户 superuser 权限，这意味着你不能安装扩展。而 PostgreSQL 的扩展生态恰恰是它最大的价值所在——没有扩展的 PostgreSQL，少了一半的灵魂。Supabase 和 Neon 在这一点上比传统 RDS 做得好，但也有各自的限制。
这些批评不是没有道理。
但批评者的参照系，始终是"有专职 DBA 团队、能自建几百台服务器"的公司。对于这类公司，自建确实更经济，云数据库的弹性溢价是实实在在的成本浪费。
问题在于，这不是所有人的处境。
对个人开发者、小团队、早期产品来说，Neon 五分钟起一个数据库，Supabase 内置认证和权限，没有运维负担，没有 DBA 招聘压力——这些价值是真实的，不是智商税。两者服务的根本上是不同规模、不同阶段的用户。
云数据库是不是杀猪盘，取决于你是谁，以及你在哪个阶段。
对大公司是杀猪盘，对独立开发者是基础设施。同一个产品，不同的用户，不同的答案。
PG 在数仓赛道的前世
说到云数仓，PostgreSQL 其实不是旁观者——它很早就参与了，只是以另一种形式。
2005 年，一家叫 Greenplum 的公司发布了一个基于 PostgreSQL 的 MPP 数据库。MPP（大规模并行处理）的思路是把一张表的数据分散到数十乃至数百个节点上，每个节点跑一个独立的 PG 实例，查询的时候并行执行，最后汇总结果。这比 Hadoop 早了将近一年，是 PG 在数仓方向上最早的一次大规模实践。
eBay 是它的早期大客户，用它处理 PB 级数据。那个年代，能在 SQL 接口下处理这种规模数据的方案屈指可数。
然后资本进来了。
2010 年 EMC 以约 3 亿美元收购了 Greenplum，2012 年并入 Pivotal，2015 年开源，2019 年 VMware 收购 Pivotal，2024 年 Broadcom 收购 VMware 之后悄悄把 Greenplum 闭源了——GitHub 仓库静静地归档，不再接受贡献。
原班开发团队出走，做了 Apache Cloudberry，把开源的火种延续下去。
Greenplum 的故事是屠龙变恶龙的数据库版本——技术上领先，先于 Hadoop 做出了 MPP 数仓，但被资本轮流倒手，每换一个主人优先级就降一点，最终在 Broadcom 手里彻底熄火。
有意思的是，Amazon Redshift 的底层也脱胎自 PostgreSQL——AWS 不太愿意大声说这件事，但技术血缘在那里。PG 的 MPP 基因，以不同的形态流淌进了云数仓时代。
说到 PG 魔改，国内也有一批"伟大作品"值得一提。
华为的 GaussDB 是其中最典型的——内核源自 PostgreSQL 9.2，经由 Postgres-XC 演化而来，这是一个基于 PG 的 MPP 扩展项目。GaussDB 在各行各业拿了大量订单，主打"国产自主可控"的政企市场。后来华为将单机版开源，命名为 openGauss，采用木兰宽松许可证。
但有几件事让人玩味：
第一，GaussDB 的宣传材料里几乎从不提 Postgres-XC 或 PostgreSQL，尽量回避与开源祖先的血缘关系。开源的 openGauss 是单机版，那个基于 Postgres-XC 的分布式版本并没有开源。
第二，GaussDB 有两个完全不同的产品线——一个基于 PG 血统，另一个则不是，但都叫 GaussDB。这种同名异物的做法，在拿订单的时候可以用"案例很多"来背书，至于是哪个 GaussDB，用户未必分得清。
第三，拿了大量订单的原因，与其说是技术领先，不如说是品牌效应和政策环境——华为被打压之后的民族情绪加成，以及国产替代的政策压力，是真实的推动力。
国内这一批"国产数据库"的兴起——GaussDB、达梦、人大金仓、南大通用——有一个共同的特点：都在不同程度上站在 PG 或 MySQL 的肩膀上，但在宣传上都倾向于淡化这一点，强调"自主可控"和"国产"标签。这不是在批评技术本身——基于开源二次开发是完全合理的工程路径，PostgreSQL License 本来就允许这样做。只是"国产"和"自主"这两个词背后的实际含义，值得每个用户自己去评估。
PG 的宽松许可证，让任何人都可以站在它肩膀上建东西，不管动机是商业的、政治的，还是工程的。这既是它的伟大之处，也是它有时候无法控制自己影响力流向的地方。
DuckDB 能走到同样的高度吗
MotherDuck 已经在做了——DuckDB 的云版本，同样是 serverless，同样是按需计费。
但 DuckDB 面临的挑战和 Neon 完全不是一个量级。
Neon 进入的是一个真空——"开发者友好的 serverless PostgreSQL"，在它出现之前没有真正的竞品，这个位置等着被填。
DuckDB 要进入的是一个已经被巨头深度占领的市场——云数仓。
Snowflake 把"把数据放到我这里来查"做成了千亿美元的生意；Databricks 从 Spark 和 Delta Lake 起家，AI/ML 一体化是它现在的主战场；AWS 有 Athena，直接查 S3 上的数据；阿里有 MaxCompute，在国内深度捆绑云生态。云数仓这个赛道早就不缺玩家了，每一家背后都有巨大的云平台做护城河。
而且这些产品的真正壁垒不是技术，是数据引力——你的数据已经在 S3 上了，Athena 直接查；已经在 OSS 上了，MaxCompute 直接查。数据沉淀在哪里，用户就被锁在哪里，迁移成本极高。DuckDB 再快，也很难撬动这些存量。
MotherDuck 的机会可能不在"替代 Snowflake"，而在更边缘的场景——本地分析、嵌入应用、数据管道中间层，这些地方 Snowflake 不想去，因为没有足够的计费空间。
我的猜测是：DuckDB 会成为分析场景里的 SQLite——无处不在，嵌入一切，但不太会以 DBaaS 的形态挑战 Snowflake 的地位。它的战场在边缘，在本地，在数据管道里，而不是在一个云控制台的 Dashboard 后面。
Neon 是填空题，MotherDuck 是抢食题。这是两件完全不同的事。
为什么是 PG
回到最开始的问题——为什么每次在约束里找出路，底下永远是 PostgreSQL？
扩展机制够开放，社区能在上面建任何东西。治理结构够稳定，没有公司能买走它、改变它的方向。许可证够宽松，商业公司可以放心押注。功能够扎实，二十年来一直在进化，每个大版本都有让人惊喜的东西。
但最根本的原因，可能就是这句话：
PostgreSQL 不只是一个数据库，它是一个平台。在它上面，别人能建出来的东西，比它自己做的还要多。
Supabase 是证明，Neon 是证明，bilxio/postgresql-fat 也是，虽然小了一点。
云数据库的下一个十年，地基还是 PG。不是因为没有挑战者，而是因为它给了挑战者在上面建东西的空间，而不是把他们挡在外面。
这种开放，是最难被替代的护城河。