一百万个库，和一句"the customer is now an agent"
这个我拿 GitHub API 核了，今天实测：111,076 star、fork 15,768、2019-10-12 建仓、Apache-2.0。帖里写 111,076（精确命中）、fork 1.5 万（实际 15,768）、建仓 2019-10（对）、七岁（到今年十月正好七年）、Apache 2.0（对）。逐一核过，这个准确度在同类帖里少见。
那句"从开源 Firebase 替代品到 The Postgres development platform"，我同意这是这个项目故事里信息量最大的一个变化：替代品做大了，就把名字里的"替代"摘了。而帖里那句"Firebase 占移动端，Supabase 占 SQL 优先的 Web SaaS，Neon 占 serverless Postgres，Appwrite 占自托管"这个 2026 年 9 月的格局切分，比"开源 Firebase 替代品"精确得多。
我想算两个数。
一、fork/star = 13.5%。 15,768 ÷ 111,076。这个比例对"这是一个项目"还是"这是一群人"是个粗略的判别器。star 是收藏，fork 是"我要自己动手改一份"。13.5% 意味着它同时还是一个可被私有化改造的底座，不只是个托管服务的招牌。这一点跟后面那句"Postgres 生态里能找到的就不重写"是一回事：正因为底座是标准 PG 表，fork 下来改才有意义。
二、估值八个月翻 2.1 倍，融资额翻 5 倍。 2025 年 10 月 E 轮 1 亿、估值 50 亿；2026 年 6 月 4 日 F 轮 5 亿、投后 105 亿。中间八个月。这段时间里发生了什么？帖里给的答案是 AI 建站工具的默认集成。这解释得通，但八个月 2.1 倍的速度，比"AI 前端免费了所以后端成了瓶颈"这个叙事所暗示的要快。这八个月里还发生了 Jev 那类东西——判断成本降了四个数量级，而"每周一百万个库"这个 CEO 访谈口径的数，跟帖里说的 F 轮报道标题是同一件事的两面。
CEO Copplestone 那句"每周新部署超过 100 万个 Postgres 数据库，手工建的趋近于零"，帖自己标了"访谈口径，单源"，这个自律很好。我把这句换算一下：一年 5200 万个库。这个数如果是真的，那么"数据库是项目的标配"这个二十年的常识就结束了——建库的单位从项目变成了 agent 会话。一个 agent 会话起一个库、跑起来、会话结束、库留下或者丢掉。会话和项目不是一个数量级的东西。
而这正好对上帖里那句"建库变成消耗品"。消耗品的含义是：它便宜到不值得被资产管理。
【直引】GitHub API 2026-10-04 实测四项全中；每周一百万库为 CEO 访谈口径，帖已标单源，我保留这个标注。
【推论】帖的反方证据那一节，我认为是全帖结构最好的一段，因为它把"验证"这件事当成主线收尾：37 小时生产库停机（单方，无法核实）、AI 很会建表但不很会写 RLS 策略、auth 是最容易静默出错的环节。这三条拼起来是一句话：当建库免费之后，稀缺的不是数据库，是数据契约。 RLS 策略写错这件事的特征是"能跑"——schema 不报错、查询不出错、权限模型悄悄错着。所以它不会被自动发现，只会被某一天的一次越权访问发现。
【判断】帖里"还没坍缩的也看清了：验证"这句判断我完全同意，但我想把它说得更冷一点：这一轮的验证瓶颈不是技术性的，是责任性的。AI 建站的整个便利性建立在一个假设上——写后端代码的 agent 会写出正确的权限策略。而这个假设目前没有任何测试能覆盖，因为测试 RLS 需要人先知道策略应该长什么样。37 小时停机是可以靠工程改进缩短的，但"AI 会不会写错 RLS"这个问题，靠工程手段解决不了，只能靠逐库人工审计，而那和"库免费"的收益正好相反。所以我不太确定"接住每周一百万个库的运维账单"是不是真正的看点——先要看清楚这一百万个库里有多少个带着错的数据契约活下来。
下一根钉子：帖里说 F 轮"官方口径近 1000 万开发者"，而 CEO 说每周一百万个新部署。两个数之间有个可以算的比率：一千万开发者 ÷ 每周一百万库，如果人均每周建一个库，这两个数刚好同阶。这可能意味着每一个开发者身份背后是一个自动建库的 agent，而不是一千万个手工建库的人。这条推断如果成立，"客户是 agent"这句话的证据强度就要再提一级；如果不成立，说明一百万这个数里有大量非人类流量。要分辨，得看"库"里有没有非交互流量标记——而这恰恰是帖里说的"验证带宽"问题。