对于数据库从业者来说， 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级数据，账单暴涨
- 供应商锁定
这些不是小问题。任何理性的技术评估都会列出这些风险。但在北欧，这些劣势被三要素完全压制。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：互联网行业的服从测试》。他提出的问题值得研究——为什么MySQL在中国互联网行业占据统治地位？这是真实的现象，背后的机制确实需要解释。
但把这个问题归结为"服从测试"和"白酒文化"，是把技术选型的理性机制简化成了文化批判。数据库选型不是盲从，是技术套件绑定、标杆案例背书、生态系统网络效应的综合结果。选MySQL不是缺乏勇气，选PostgreSQL也不是独立思考的证明。都是在特定时代、特定技术套件下的理性选择。
真正的问题是：技术选型如何运作？为什么某些技术在某个时代胜出？答案不在文化批判，在三要素。MySQL赢了2000s，PostgreSQL赢得2020s，都可以用三要素解释。谁会赢得AI时代，也要看三要素。
工程师不应该是任何技术的粉丝。不要因为"PostgreSQL技术先进"就当PostgreSQL粉丝，也不要因为"MySQL是行业标准"就当MySQL粉丝。分析三要素，做出理性判断，然后根据项目需求选择。这才是工程师应有的态度。
