今天很多团队一打开项目，几乎都会看到：
schema.sql或一串 migration 文件- 代码里堆着 ORM 模型、索引声明和事务边界
- 配置里写着主从、只读、副本、连接池、重试
- 文档里讨论
MySQL、PostgreSQL、MongoDB、Redis、TiDB、Aurora - 预算表里还躺着一行越来越难看的云数据库账单
我们很容易把这一切当成空气：数据库本来不就是把数据存进去，再稳定取出来吗？
可如果你退一步，把数据库从“后端基础设施”这个习以为常的标签里抽出来，只看它替团队定义了什么，会问出一个很不浪漫、但很真实的问题：
如果数据库只是存储技术，为什么每隔几年，行业就要重新争一次“什么叫正确”“什么叫够快”“什么叫够便宜”？
为什么有的系统宁可多花钱，也要死守事务和强约束；有的系统宁可把一致性债务丢给应用层，也要先换来扩展性和开发速度；还有的系统嘴上说自己在卖数据库，实际卖的是托管、迁移、备份、跨区容灾和退出成本？
这套 《数据库江湖》 想讲的就是这些事。
它不是“十大数据库选型指南”。
也不是 Oracle、MySQL、PostgreSQL、MongoDB 的产品编年史。
更不是把 ACID、CAP、MVCC、LSM、Raft 这些词重新压缩成一篇术语扫盲。
它更像一部数据秩序如何被反复改写的历史：谁有权规定什么叫“正式数据”、谁有权决定一致性值多少钱、谁把运维难度包装成商业承诺、谁又在下一轮技术迁移里，把旧账单改成新的科目继续寄给开发团队。
这套系列讲什么
我想追的母题，可以用一句话压住：
数据库每次范式切换，表面上都像技术升级，实质上都在重分配谁承担正确性、扩展性与运维复杂度。
你会在这套系列里反复看到几组拉扯：
- 强约束、规范化与事务完整性，对上 灵活模型、弱约束与应用侧兜底（模型层）。
- 单机时代的确定正确，对上 分布式时代的可扩展与高可用（工程层）。
- DBA / 数据平台的集中治理，对上 业务团队自助、快速交付与低门槛试错（组织层）。
- 高价一体化数据库承诺，对上 开源普及、云托管与后续商业化回收（商业层）。
人物会出现，但他们只服务于冲突结构：没有制度后果，就不值得占用篇幅。
你可以把主线记成八篇
01｜数据库江湖（一）：关系型数据库真正卖出去的，不只是表和 SQL，而是企业秩序
为什么“把数据放进表里”最后不只是技术方案，而成了企业默认秩序。
02｜数据库江湖（二）：MySQL 真正改变的，不只是价格，而是数据库掉进了每个开发者手里
数据库为什么从 DBA 领地掉进每个开发者手里。
03｜数据库江湖（三）：PostgreSQL 总在旧秩序快失灵时被重新想起，因为它一直在给关系型续命
为什么它总在旧秩序快失灵时被重新想起。
04｜数据库江湖（四）：NoSQL 真正拆掉的，不是 SQL，而是“一种秩序统治所有数据”的幻觉
不是 SQL 失效了，而是“单一正确性秩序”失效了。
05｜数据库江湖（五）：NewSQL 不是回到过去，而是大家终于承认还想要 SQL、事务和熟悉的秩序
大家还是想把事务和 SQL 拿回来，只是这次得在分布式世界里重写代价。
06｜数据库江湖（六）：云数据库卖的从来不只是托管，而是把控制权悄悄搬回平台手里
数据库真正变成了“租来的能力”，控制权也跟着搬家。
07｜数据库江湖（七）：数据库没有终局，只有一轮轮把复杂度换个承担者的旧账重写
今天团队在 schema、缓存、同步、搜索、分析和账单之间的焦虑，是半个世纪旧账的最新形态。
第 0 篇就是你现在读的总序：先把总命题立住，再交代这套系列与仓库里其它“江湖”系列怎么互相照亮。
为什么数据库特别适合写成“江湖”
因为数据库这个领域，几乎完美命中了“江湖体”的四条筛选线：
- 它确实吵了很多年：从关系模型到对象数据库、从 NoSQL 到 NewSQL、从自建到托管，每一轮都不是几个月热度，而是十年以上的拉锯。
- 它背后从来不只是技术：许可证、企业销售、咨询服务、云平台、DBA 角色、组织流程，全部缠在一起。
- 今天大家还在替历史决定买单：schema 设计、数据迁移、跨库同步、兼容旧应用、云账单、厂商锁定，都是当代团队每天会痛到的东西。
- 它有足够多硬材料：论文、官方文档、产品发布说明、公司公告、架构白皮书、许可证与服务条款，比许多别的题材更容易挂锚点。
所以真正值得追问的，从来不是“哪种数据库最终赢了”，而是：
为什么数据库世界每次号称要解决旧问题，最后都只是把复杂度换个地方藏起来。
和已经写过的系列怎么接起来
如果你读过开源江湖，会记得：很多技术路线之争，最后都会长成许可证、治理模式与商业回收方式之争。数据库世界把这件事演得更直白，因为它离客户预算、企业采购和云收入更近。
如果你读过前端工程化江湖，会记得：复杂度不会凭空消失，它只会从“你自己手写”变成“你维护一条更长的工具链”。数据库也一样：从自建到托管，从单库到多模，从 SQL 到 NoSQL 再到分布式 SQL，复杂度并没有少，只是承受者在换。
如果你读过跨端江湖，会记得：每一代“统一抽象”都承诺让你少想底层，但现实总会用性能、边界和平台权力把抽象层重新戳穿。数据库世界里的“万能存储”神话，也一次次死在这里。
《数据库江湖》不是重复讲这些故事，而是给它们补一层更硬的基础设施前传：很多今天被你我当成“后端常识”的东西，其实都是半个世纪权衡、妥协和商业收编之后留下的默认值。
写作纪律（本系列自用）
- 三层标注：可核对事实（论文、文档、公告）｜当事人回忆｜坊间传说。第三层绝不写成铁案。
- 强判断必挂锚：论文 DOI、官方文档、产品发布说明、许可证与服务条款，优先于回忆录与访谈摘抄。
- 产品宣传与制度后果分开：厂商说“更简单”“更一致”“更开放”，不等于团队真实成本真的下降。
- 人物与口水战少写：除非能回到制度后果，否则不把创始人气质或社区互喷当正文推进器。
推荐阅读顺序
按篇号从 00 读到 07 最顺：先立住数据库不是中性容器，而是复杂度分配器，再看每一轮范式切换如何重新定义默认秩序。
如果你时间很少，至少读完 00、02、04、06、07：你会拿到“数据库权力如何搬家”的主骨架。
先收束到一个追问
如果数据库只是“把数据放进去，再按条件取出来”，为什么行业会在关系型、NoSQL、分布式 SQL 和云托管之间反复摇摆半个世纪？
关键人物与组织速览
- Edgar F. Codd：关系模型提出者；理解为什么“表”和“关系”能从理论语言变成工业秩序，绕不开他。
- Oracle：商业数据库时代最重要的企业象征之一；理解数据库如何被卖成企业承诺，绕不开它。
- MySQL / MySQL AB：理解数据库如何从高门槛企业资产变成 Web 团队默认零件，绕不开它。
- PostgreSQL 社区：理解开源关系型如何长期吸纳新需求却维持可信度，绕不开它。
- Google / Amazon：理解 NoSQL 与分布式数据库心智为何变化如此剧烈，绕不开
Bigtable、Dynamo、Spanner这些公开论文。
参考与延伸阅读
E. F. Codd, A Relational Model of Data for Large Shared Data Banks
DOI: https://doi.org/10.1145/362384.362685MySQL 8.4 Reference Manual
https://dev.mysql.com/doc/refman/8.4/en/PostgreSQL — History
https://www.postgresql.org/about/history/Bigtable: A Distributed Storage System for Structured Data
https://research.google/pubs/pub27898/Dynamo: Amazon's Highly Available Key-value Store
https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdfSpanner: Google's Globally Distributed Database
https://research.google/pubs/pub39966/SQLite — Appropriate Uses For SQLite
https://sqlite.org/whentouse.html
下篇预告：为什么“表”这种看起来如此普通的东西，最后会变成企业世界里最像正统的那种数据秩序。