# MySQL赢了2000s，PostgreSQL赢得2020s，谁将赢得AI时代？——数据库选型的三要素分析法 LLMS 索引： [llms.txt](/llms.txt) --- > 原作者：瑞典马工 对于数据库从业者来说，2026 年，只有一个重要的问题：谁将赢得 AI 时代的数据库市场？ 这不是技术特性的比拼，也不是营销预算的较量。我认为决定数据库胜负的是三个要素：**技术套件、标杆案例、生态系统**。MySQL 用 LAMP + Facebook + Stack Overflow 赢得 2000s。PostgreSQL 用 Heroku/Vercel + Instagram + 云厂商赢得 2020s。都是三要素在起作用。 AI 时代谁会赢？除了骗子，没有人敢说自己已经有答案了。但是我们可以从历史中借鉴一些经验，抽取通用的理论，然后用它来帮助我们拨开一些迷雾。毕竟，时间不等人，窗口期就是 2026 年了。 --- ## 为什么 MySQL 赢了 2000s MySQL 主宰 2000s 不是因为功能特性比 PostgreSQL 好，而是因为满足了三要素。 ### 要素一：技术套件 - LAMP 的深度绑定 **LAMP = Linux + Apache + MySQL + PHP**。这不只是四个软件的打包，而是深度技术集成：PHP 有原生 MySQL 驱动（mysql_connect，mysqli），Apache 有针对 PHP+MySQL 优化的模块，主机提供商的基础设施假设你用 LAMP，教程和文档默认 LAMP 技术栈。 更重要的是分发渠道：2000s 的共享主机时代，70% 的主机提供商（Bluehost，HostGator 等）提供 cPanel 一键安装器（Softaculous，Fantastico）。你不需要懂技术，点一下按钮，WordPress/Joomla 就装好了，MySQL 也跟着来了。那时候建网站的人，很多是小企业主，不是工程师。他们根本不知道"选择数据库"这件事，主机提供商替他们做了决定。 **你不是"选择 MySQL"，你是"选择 LAMP"，MySQL 随之而来。** 即使你想用 PostgreSQL，共享主机提供商也不支持。为什么？因为 PostgreSQL 在 2000s 有关键技术差距：MySQL 早在 2000s 初就有主从复制，而 PostgreSQL 直到 2010 年（9.0 版本）才有流式复制——整整 10 年的技术代差。Web 2.0 时代，复制是扩展 web 应用的必需品。技术不成熟 + 主机提供商不支持，PostgreSQL 连进入比赛的资格都没有。 ### 要素二：标杆案例 - Facebook 证明 MySQL 能支撑规模 2000s 最大的技术焦虑是：这个数据库能不能支撑规模？ Facebook 用 MySQL 扩展到 10 亿用户，这个故事消除了所有担忧。不只是 Facebook，还有 GitHub，Twitter（早期架构），中国的淘宝、腾讯、百度，都用 MySQL 支撑大规模应用。这些公司的工程博客、技术大会演讲，把 MySQL 扩展经验变成公开知识。 标杆案例的作用不只是技术可行性证明，更重要的是降低决策成本。创业公司创始人拿着商业计划书找投资人，说"我们用 MySQL，Facebook 也用 MySQL"，投资人立刻理解。说"我们用 PostgreSQL，因为 ACID 实现更完整"，得花 30 分钟解释为什么不用行业标准。工程师跟老板提方案，说"行业标准"四个字就够了，不需要写详细的技术评估报告。 更妙的是政治安全：失败了可以说"我们遵循了行业最佳实践"（责任分散），成功了是我的功劳（功劳集中）。理性的启发式策略。 标杆案例还创造人才池：大公司用 MySQL，工程师就学 MySQL，人才市场自然形成。招聘时写"MySQL DBA"，简历一堆；写"PostgreSQL DBA"，简历寥寥。 ### 要素三：生态系统 - 让技术债变得可以容忍 MySQL 有很多设计问题：默认字符集是 latin1 不是 UTF-8，真正的 UTF-8 叫 utf8mb4；TIMESTAMP 只支持到 2038 年；DDL 不支持事务；GROUP BY 可以选择非聚合列（违反 SQL 标准）。PostgreSQL 粉丝最爱列举这些缺陷。 **但生态系统让这些问题变得可以容忍。** MySQL 的 Stack Overflow 问题数量是 PostgreSQL 的 5 倍。遇到字符集问题？网上有成千上万篇 utf8mb4 教程，告诉你怎么改配置、怎么迁移数据、怎么避免踩坑。复制延迟问题？有 Vitess、Orchestrator 等第三方工具帮你管理。没有 DDL 事务？最佳实践已经演化：用工具做模式迁移，加版本控制，先在测试环境测试。中文社区特别活跃，任何问题都能找到中文解答。 生态系统的存在，让工程师不需要成为数据库专家（被迫的），可以专注业务逻辑。PostgreSQL 技术上再好，遇到问题找不到答案，就得啃官方文档、读源代码、去邮件列表问问题，时间成本高太多。 更强的锁定来自 WordPress：WordPress 只支持 MySQL，占全球网站的 40%。这些网站永远不会迁移到 PostgreSQL，迁移成本太高：不只是数据，还有插件、主题、运维流程。数据库迁移项目只有 17% 能按时按预算完成（Gartner 数据），30% 成本超支，平均 4 小时停机时间损失\$28k。有这个生态系统，谁还冒险迁移？ **三要素的正反馈循环：**LAMP 技术套件带来大量用户 → 用户中产生 Facebook/BAT 这样的标杆案例 → 标杆案例吸引更多创业公司模仿 → 用户贡献 Stack Overflow 答案、写教程、开发工具 → 生态系统降低使用门槛 → 更多用户选择 MySQL。 MySQL 主宰 2000s，三要素缺一不可。 --- ## 为什么 PostgreSQL 赢得 2020s PostgreSQL 的崛起用相同的三要素，但机制完全不同。 ### 要素一：技术套件 - 从具名技术栈到平台默认 LAMP 时代的特征是具名技术栈捆绑。它有明确的缩写：LAMP，WAMP，MAMP。开发者主动选择，说"我们是 LAMP 团队"。技术栈是完整的，从操作系统到应用层。分发渠道是共享主机的 cPanel 一键安装。 云时代的机制变了。Rails 用 PostgreSQL，但没有"RHP Stack"这个名字。开发者被动继承：选择框架/平台，数据库自动跟随。不包含操作系统层，因为基础设施已经抽象化（这是云的本质）。分发渠道是平台默认 + 启动模板。 平台默认配置更强大，因为它是隐形标准化。 Heroku 是第一个证明这个机制的平台。2007 年创立时，Heroku 只提供 PostgreSQL——不是选择，是约束。你要用 Heroku 部署 Rails，就必须用 PostgreSQL。DATABASE_URL 环境变量约定成为 Rails 社区标准，`git push heroku main`的部署流程和 PostgreSQL 深度集成。开发者根本没有"选择"这个步骤，PostgreSQL 就在那里了。结果：Heroku 管理了 2 百万+个 PostgreSQL 数据库。 Vercel 把这个机制推向极致。2023 年推出 Vercel Postgres，背后是 Neon PostgreSQL（大多数开发者不知道）。当你运行`create-next-app`，启动模板已经配置好 PostgreSQL + Prisma。Next.js 的官方教程和文档假定你用 PostgreSQL。`npx vercel db init`自动部署 PostgreSQL。开发者说"我用 Next.js"时，PostgreSQL 是隐含的。 平台默认配置比具名技术栈捆绑更强大，因为它的摩擦更低。LAMP 时代，你得主动说"我选择 LAMP"，这是个显性决策。Vercel 时代，数据库选择直接消失了——你说"我用 Next.js"时，根本不会提数据库，但 PostgreSQL 已经在那里了。决策疲劳降到零。 更妙的是品牌推广的成本。LAMP 需要一个朗朗上口的缩写，需要营销推广"LAMP 技术栈"这个概念。平台默认配置不需要，它搭 Next.js 或 Rails 的便车——框架火了，数据库自然跟着火。这是隐形的标准化，比显性的品牌推广更有效。 锁定也更强。LAMP 时代你可以只换 MySQL，其他保留。平台默认配置时代，切换数据库意味着放弃平台的优化：Vercel 为 PostgreSQL 优化的连接池、监控面板、部署流程，你换成 MySQL 就都没了。商业设计使然。 PostgreSQL 不是靠功能特性赢的。它赢在成为新一代平台的默认选择，而开发者对此甚至没有意识。 ### 要素二：标杆案例 - Instagram 和云厂商的隐性背书 MySQL 时代的标杆案例是"证明能扩展"：Facebook 扩展到 10 亿用户，证明 MySQL 能支撑大规模负载。这是防御性的证明——消除担忧。 PostgreSQL 时代的标杆案例是"证明够现代"：Instagram 用 PostgreSQL 从零扩展到数亿用户，但重点不是"它能扩展"，而是"精英工程团队选择了它"。Apple，Spotify，Reddit 用 PostgreSQL。中国新一代公司像探探也用 PostgreSQL。这些案例传递的信息不是"它能用"，而是"前瞻性公司用它"。 更强大的是云厂商的隐性背书。AWS、Google Cloud、Azure 都大量投资 PostgreSQL 托管服务。Stack Overflow 调查显示 58% 的专业开发者用 PostgreSQL，被评为"最受推崇"数据库。这创造了认知：PostgreSQL 是未来的选择，MySQL 是遗留技术。 ### 要素三：生态系统 - 云厂商 + 经济激励 三大云厂商（AWS，Google，Azure）都把 PostgreSQL 作为战略重点。新版本 PostgreSQL 17 发布几个月内，云厂商的托管服务就更新了。MySQL 的更新？慢得多，因为 Oracle 的授权让云厂商不舒服。商业问题。 经济激励也在发挥作用。PostgreSQL 是 BSD 许可证，完全免费；MySQL 商业使用要付费（\$2k-5k/年）。更显著的是人才市场：PostgreSQL DBA平均年薪\$133k，MySQL DBA \$73k——接近 2 倍差距。这告诉年轻工程师该学什么。 Supabase 打开了新的分发渠道。它是"开源 Firebase 替代方案"，完全构建在 PostgreSQL 上。后端即服务市场，Firebase 用 NoSQL，Supabase 用 PostgreSQL——想要 Firebase 体验但要关系型数据库的开发者，自然选 PostgreSQL。 技术成熟度也终于赶上了。PostgreSQL 2010-2024 持续改进：流式复制（2010），JSONB（2014），原生分区，并行查询。到新技术套件形成时（Heroku/Vercel），技术已经就绪。生态系统现在帮 PostgreSQL 克服剩余的问题，比如水平扩展的复杂性。 **三要素的新循环：** 平台默认配置带来新用户 → 新用户中有 Instagram/Apple 这样的标杆案例 → 标杆案例吸引云优先创业公司 → 云厂商投资托管服务 → 经济激励吸引人才 → 生态系统持续成长。 MySQL 用 LAMP + Facebook + Stack Overflow 赢得 2000s。PostgreSQL 用 Heroku/Vercel + Instagram/OpenAI + 云厂商赢得 2020s。机制相同，但更隐蔽、更强大。 --- ## 谁将赢得 AI 时代？ 理解了三要素，就能预测：下一个赢家必须满足三个条件。 ### 条件一：成为 AI 编程套件的一部分 不能只追求兼容性（那是防守），要找到下一个大趋势。 传统路径是绑定新兴语言/框架（Rust？Deno/Bun?）。但这些都是渐进式创新，不是范式转变。风险：投入巨大，可能市场太小。 真正的机会在 AI 编程套件。不是愚蠢的向量数据库——那是为 AI 应用数据服务的，pgvector 已经做了。真正的机会是为 AI 编程工作流设计的数据库。 问题重新定义：AI 编程者（像我）每天写代码，什么数据大语言模型管不好？ 大语言模型擅长代码生成、文本处理、模式匹配。但不擅长结构化数据持久化、事务一致性、复杂关系查询、模式演进追踪、数据完整性约束——这些正是数据库应该补充的地方。 可能的 AI 编程套件长什么样？AI 编程助手（Claude Code，Cursor 等）+ 针对 AI-人类协作优化的数据库 + 管理"大语言模型不该碰的数据"的工具。比如会话状态、用户偏好、结构化配置、审计日志——这些数据需要强一致性，不能让大语言模型随意修改。 为什么这是真正的机会？因为 AI 编程是范式转变，现在的数据库都为人类编程者设计。AI + 人类协作工作流需要不同的数据管理模式。谁抢到先发优势建立这个技术套件，谁就是下一个 PostgreSQL。 赌对了 = Heroku 的 PostgreSQL。赌错了 = 无人问津。 ### 条件二：打造代表未来的标杆案例 标杆案例必须是创新的，能代表未来。Facebook 对 MySQL 的价值在于证明"能支撑规模"，这是 2000s 的焦虑。未来的焦虑是什么？AI 工作流能不能可靠运行，会话状态能不能一致管理，AI 生成的数据能不能正确存储。 Supabase 和 OpenAI 合作，为 ChatGPT 插件提供 PostgreSQL + pgvector 的知识库方案。这不是偶然：AI 需要既能做语义搜索（pgvector），又能保证事务一致性（PostgreSQL）的数据库。这就是 AI 时代的标杆案例：不是证明"能扩展"（那是上个时代的问题），而是证明"能同时处理结构化数据和向量搜索"。 这个案例传递了信号：PostgreSQL 理解 AI 时代的需求。其他数据库厂商如果想赢得 AI 时代，需要类似的案例——某个知名 AI 产品公开选择某个数据库，并解释原因。没有这样的标杆案例，技术再好也难推广，就像 Mnesia 有技术优势，但除了 Klarna 谁在用？ ### 条件三：加入既有生态系统 与其从零建立生态系统，不如加入既有生态系统——就像 AI 编程生态系统。 AI 编程工具（Claude Code，Cursor）已经有庞大的用户群。如果某个数据库成为这些工具的默认选择，就能立即获得生态系统：开发者社区、教程内容、工具集成。这比从零积累云厂商支持、对象关系映射、监控工具要快得多。关键是找对生态系统，加入进去，而不是自己造一个。 --- ## 三要素理论的验证 三要素理论不仅能解释 MySQL 和 PostgreSQL 过去三十年的历史，还可以用于解释很多 DB 选型现象。 ### 用三要素理论看中国数据库厂商的 Oracle 兼容性策略 OceanBase、PolarDB、GaussDB 都大量投入 Oracle 兼容性，不只是 SQL 方言，还有 PL/SQL、包、存储过程的完整模拟。为什么？ 因为中国企业（银行、电信、政府）的 Java + Oracle 组合是既定技术套件。Oracle 兼容让企业无需改代码，中间件继续运作，运维流程不变。Oracle 的庞大存量用户就是现成的标杆案例，"跟 Oracle 一样"就是最好的证明。DBA 团队的知识直接复用，培训成本几乎为零。 "借用"Oracle 的三要素，比创造全新技术套件/标杆/生态要快得多。理性的防守策略。 ### 用三要素理论看具体的项目架构决策 马工本人在一个新项目中用三个数据库：S3 存业务对象，PostgreSQL 存请求状态，DynamoDB 存编排服务状态。为什么不统一用 PostgreSQL？ 因为编排服务用 AWS Step Functions，而 Step Functions + DynamoDB 是集成套件。开发工具包优化、权限配置简单、监控默认集成。用 PostgreSQL 要自己写集成代码、配网络安全组、设连接池。单独换数据库不划算，只有换整个套件才合理。但是用 Temporal 替换 Step Functions，不是 DB 层面的决策。 技术套件的绑定力，在微观层面同样成立。 ### 用三要素理论看 BigQuery 在北欧的流行 BigQuery 在北欧的流行程度远超其他地区。Validio 对北欧独角兽和高速成长公司的调研显示，BigQuery 采用率达 45%，远超 Snowflake 和 Redshift。全球范围内，BigQuery 与竞争对手的差距很小甚至落后，但在北欧市场，BigQuery 占据统治地位。为什么？三要素完美解释。 **标杆案例：从 Spotify 到金融科技三巨头**。Spotify 把整个大数据平台从 2500 节点的 Hadoop 集群迁移到 Google Cloud Platform，用 BigQuery 替代 Hive，开源了 Scio（Scala + Apache Beam API）处理每天超过 1 万亿条事件。Spotify 不只是用 BigQuery，还公开分享架构演进，工程博客详细记录迁移过程。这创造了标杆效应。 更强的信号来自金融科技公司的成功退出：Zettle（2018 年被 PayPal 以 22 亿美元收购）、Tink（2021 年被 Visa 以 18 亿欧元收购）都用 BigQuery 作为数据仓库。King（动视暴雪子公司）、IKEA 也在用。当北欧最成功的科技公司都用 BigQuery，并且被国际巨头高价收购，这传递了强烈信号："这个技术栈能支撑独角兽成长和成功退出"。 **技术套件：跨云架构范式**。真正有意思的不是"全用 GCP"，而是一个跨云的架构范式：**AWS 处理业务逻辑和实时流，BigQuery 做分析和报表**。 看 Tink 的做法：用 AWS Kinesis 采集支付和账户数据流，落到 S3 数据湖，然后用 Airflow 编排转换任务，最后在 BigQuery 里跑 SQL 做分析。 Zettle 也是类似思路。交易系统跑在 AWS EC2 和 RDS 上，600GB 的主数据库处理实时支付。但商户分析报表？全在 BigQuery。实时交易需要低延迟，AWS 的 VPC 和 RDS 能保证；历史数据分析需要扫描大量记录，BigQuery 的列式存储和并行查询更快。各取所长。 这个跨云模式几乎成了北欧金融科技的标准范式。不是被 GCP 营销说服，而是理性选择：AWS 运行业务逻辑，BigQuery 做数据分析。当 Zettle 和 Tink 都被高价收购，这个架构就被验证了。后来的创业公司不需要再评估——直接复制，招这两家出来的工程师，照着已验证的最佳实践做。 **生态系统：人才市场与工具栈标准化**。Spotify 培养了大批 BigQuery 专家，这些人离职后去创业公司、咨询公司，带着 BigQuery 技能。招聘市场形成：职位描述写"BigQuery 经验优先"，候选人简历里写"Spotify 数据工程师，精通 BigQuery"。Tink 的技术负责人说得很直白，选 BigQuery 是因为"需要最少的工程资源，同时提供最高的生产力". 更重要的是工具栈的标准化。Validio 的调研显示，北欧数据团队有明确的技术栈共识：Airflow 做编排，dbt 做转换，BigQuery 做仓库，Looker 做可视化，Postgres 做事务数据库，Kafka 做流处理。这六个工具成为事实标准。新公司不需要重新评估技术选型——直接用这个栈，在 LinkedIn 上搜索"Stockholm + BigQuery + Airflow"就能找到候选人，Stack Overflow 上的问题都有北欧工程师回答过。 这个生态系统的网络效应极强：更多公司用 → 更多工程师学 → 更多教程和最佳实践 → 更容易招人 → 更多公司用。其他欧洲地区没有这个效应，即使想用 BigQuery 也缺少本地支持。 #### BigQuery 的明显劣势 有意思的是，BigQuery 有很多明显的技术劣势： - **没有索引**。传统数据库依赖索引优化查询，BigQuery 强制全表扫描，只能靠列式存储和分区缓解 - **没有主键约束**。数据完整性完全靠应用层保证，插入重复数据不会报错 - **SQL 方言怪异**。嵌套和重复字段的语法跟标准 SQL 差异巨大，学习曲线陡峭 - **成本不可预测**。按扫描数据量计费，一个写错的 JOIN 可能扫描 TB 级数据，账单暴涨 - **供应商锁定**。没有真正的迁移路径，数据和查询都深度绑定 GCP 这些不是小问题。任何理性的技术评估都会列出这些风险。但在北欧，这些劣势被三要素完全压制。Spotify 每天处理 1 万亿事件，Zettle 被 PayPal 以 22 亿美元收购，Tink 被 Visa 以 18 亿欧元收购——都用 BigQuery。这就够了。技术套件已经建立（AWS + BigQuery 跨云范式），人才市场已经形成（Airflow + dbt + BigQuery 标准栈），没人在乎索引或主键约束。 从 Spotify 一家公司，扩散到整个北欧科技圈，BigQuery 采用率 45%（全球其他地区远低于此）。标杆案例（成功退出） → 技术套件锁定（跨云架构范式） → 生态系统自增长（工具栈标准化）。三要素在地区层面同样成立，并且强大到可以让明显的技术劣势变得无关紧要。 --- ## 结论 MySQL 用 LAMP + Facebook + Stack Overflow 赢得 2000s。PostgreSQL 用 Heroku/Vercel + Instagram + 云厂商赢得 2020s。谁会赢得 AI 时代？ ### 目前的领先者：PostgreSQL 从三要素看，PostgreSQL 在 AI 时代有先发优势。Supabase 和 OpenAI 的合作是标杆案例，pgvector 证明它能同时处理结构化数据和向量搜索。云厂商的投资、开发者社区、工具生态都已形成。 但这不是定局。PostgreSQL 的优势来自 2020s 的云厂商生态，不是 AI 编程套件。谁能成为 Claude Code、Cursor 的默认数据库，谁就有机会弯道超车。关键是 2025-2026 这两年——AI 编程工具的技术套件正在形成，第一个 AI 编程项目的大规模成功案例即将出现。谁能抓住这个窗口期，谁就是下一个 DB 市场赢家。 ### 研究问题，而不是当粉丝 我的朋友冯若航写了一篇[《MySQL：互联网行业的服从测试》](/db/mysql-baijiu/)。他提出的问题值得研究——为什么 MySQL 在中国互联网行业占据统治地位？这是真实的现象，背后的机制确实需要解释。 但把这个问题归结为"服从测试"和"白酒文化"，是把技术选型的理性机制简化成了文化批判。数据库选型不是盲从，是技术套件绑定、标杆案例背书、生态系统网络效应的综合结果。选 MySQL 不是缺乏勇气，选 PostgreSQL 也不是独立思考的证明。都是在特定时代、特定技术套件下的理性选择。 真正的问题是：技术选型如何运作？为什么某些技术在某个时代胜出？答案不在文化批判，在三要素。MySQL 赢了 2000s，PostgreSQL 赢得 2020s，都可以用三要素解释。谁会赢得 AI 时代，也要看三要素。 工程师不应该是任何技术的粉丝。不要因为"PostgreSQL 技术先进"就当 PostgreSQL 粉丝，也不要因为"MySQL 是行业标准"就当 MySQL 粉丝。分析三要素，做出理性判断，然后根据项目需求选择。这才是工程师应有的态度。 --- 发布版本：[微信公众号转载页](https://mp.weixin.qq.com/s/KGERTSOLvczm1dGmoBe4lA)