8 亿用户。
这是 ChatGPT 和 OpenAI API 平台目前承载的庞大用户基数。
按照教科书式的“分布式架构圣经”，面对这种天文数字级的流量，你的第一反应是什么？
是搞几百个节点分库分表？还是上 CockroachDB 这种原生分布式 SQL 数据库？
OpenAI 的答案让人大跌眼镜：**一个 PostgreSQL 实例。**没错，不是复杂的分布式集群，也不是眼花缭乱的分片方案。他们就靠着 Azure 上的一个 PostgreSQL 主节点（Primary），扛下了所有写入请求；再加上不到 50 个只读副本，处理了每秒数百万次的查询。
这听起来像是在开历史的倒车，但这恰恰是 OpenAI 最“狡猾”的地方。
打破规模焦虑的“极简主义”
很多人把“高并发”和“必须分布式”画了等号。
一旦流量上来，架构师们还没看清楚瓶颈在哪，就开始忙着重构系统，生怕被贴上“技术落后”的标签。OpenAI 这次直接摊牌了：别慌，先看看你的工作负载到底长什么样。
在 OpenAI 的技术披露中，工程师 Bohan Zhang 透露，过去一年他们的 PostgreSQL 负载增长了超过 10 倍，而且还在涨。
但他们没有选择把系统推倒重来。这套“单主多从”的架构，不仅跑通了，还跑出了极低的 P99 延迟（低两位数毫秒），以及高达 99.999% 的可用性。
这给所有陷入“规模恐慌”的企业上了一课：有时候，你不需要更复杂的架构，你只需要更极致的优化。## 当“老古董”遇上黑科技
PostgreSQL 并不是为超大规模分布式场景而生的，它的 MVCC（多版本并发控制）机制在处理大量写入时，会因为行版本复制导致写放大。
OpenAI 没有死磕这个短板，而是选择了“扬长避短”。
ChatGPT 和 API 的业务特性是什么？读多写少。
既然是读多写少，那就把读取压力全部甩给那 50 个跨区域的只读副本，主节点只专心写数据。
为了榨干这个“单主节点”的性能，OpenAI 玩出了花：* 连接池优化：把连接时间从 50 毫秒硬生生砍到了 5 毫秒；
- 缓存锁定：防止缓存失效时的“惊群效应”，避免数据库瞬间被流量冲垮；
- 多层防御：在应用层、代理层、查询层全加上速率限制，把低优先级和高优先级的流量隔离开。
这就像是一辆老式跑车，没换引擎，但把进气、排气、轮胎全改了，照样在赛道上超车。
ORM 框架里的“隐形杀手”
在这场极致的优化游戏中，OpenAI 还发现了一个让无数开发者后怕的细节。大家为了开发方便，都喜欢用 ORM 框架（比如 Django、SQLAlchemy、Hibernate），让代码自动生成 SQL 查询。
这很爽，但也很危险。
OpenAI 在生产环境抓到了一个“罪魁祸首”：一个由 ORM 自动生成的查询，竟然连接了 12 张表。
这个看似不起眼的查询，在流量高峰期直接引发了多次严重事故。
这就是所谓的“便利陷阱”。框架帮你省下了写 SQL 的时间，却可能在关键时刻背刺你。OpenAI 的对策很粗暴：死磕 ORM 生成的 SQL。
他们把审查生产环境里的自动生成查询变成了标准动作，绝不让任何一行“偷懒”的代码成为系统的阿喀琉斯之踵。
严苛到“变态”的纪律
要在单节点上支撑 8 亿用户，光有技术优化不够，还得有铁一般的纪律。
OpenAI 制定了一套近乎苛刻的数据库“宪法”：
- 禁止全表重写：任何会触发全表重写的 Schema 变更，想都别想；
- 5 秒超时：Schema 变更必须 5 秒内完成，超时即失败；
- 杀掉长查询：任何阻碍数据库维护的长查询，自动终止；
- 慢速回填：为了不影响线上业务，数据回填的速率限制极其严格，哪怕一个操作要跑上一个多星期。这种“宁可慢，不可乱”的工程哲学，才是支撑 8 亿用户流量的真正基石。
不迷信“新”，也不盲从“旧”
当然，OpenAI 并不是在死守 PostgreSQL。
他们采取了一种非常务实的“混合策略”：
PostgreSQL 里不再新增表了。
所有新的、写入密集型的业务，默认分流到 Azure Cosmos DB 这种分片系统里；只有那些适合单主节点的老业务，才留在 PostgreSQL 里继续压榨性能。这给行业带来的启示是深刻的。
不要为了追求技术时髦而搞“大跃进”式的重构，也不要因为怀旧而拒绝新工具。
架构决策，应该由你的工作负载模式说了算，而不是由技术圈的流行风向标说了算。
OpenAI 用 8 亿用户的实战经验告诉我们：在找到真正的瓶颈之前，别急着把你的系统拆得七零八落。
参考链接：
https://venturebeat.com/data/how-openai-is-scaling-the-postgresql-database-to-800-million-users