关系型、NoSQL 还是全能 PostgreSQL？MySQL、Redis、MongoDB 与现代数据库选型指南

每隔一阵子，技术圈就会冒出一句口号：今年一定要上 NoSQL！MongoDB 真香！然后过两年，又有人改口：还是 PostgreSQL 靠谱。如果你被这些风向搞晕了，别慌——真相是，SQL 和 NoSQL 从来不是二选一的生死局，而是看你手里的数据长什么样。

延伸阅读

更多相关攻略推荐：泛域名 SSL 证书自动化避坑：Acme.sh + DNS API 、BGP 是互联网的"高德地图"：打开网页时，数据是这样找路的、【优化线路 02】BGP / AS4837 常规线路年付 10 美元、高级玩家玩出花：如何在 VPS 上广播自己的 IP 地址？BYOIP、计算机科学两大难题之一：缓存失效与 CDN 瞬时刷新奥秘。

一、先破个误区：SQL 和 NoSQL 不是二选一

NoSQL 这个词本身就误导人。它字面是 Not Only SQL（不只是 SQL），而不是 No SQL。它其实是一把大伞，下面遮着文档库、键值库、宽列库、图数据库、时序库、向量库等起码七种完全不同的数据模型。把 SQL vs NoSQL 当成轿车 vs 非轿车来比，本来就不公平。真正该问的是：我的数据形态和访问模式，适合哪种模型？

二、关系型数据库的辉煌：ACID 与 SQL

关系型数据库（RDBMS）从 1970 年埃德加·科德（Edgar Codd）提出关系模型算起，已经统治了半个世纪。它把数据存进表（行和列），表之间通过主键外键关联，你用 SQL 这种声明式语言提问题——你只说要什么，数据库自己决定怎么找。

它给开发者三样容易低估、直到失去才懂珍贵的东西：第一，Schema（模式）会替你挡住畸形写入；第二，事务（Transaction）让你把好几步改动打包成全有或全无的一个单元；第三，即席查询（Ad-hoc Query），你没预料过的问题，靠 JOIN、聚合也能现场答出来。

支撑这些的是 ACID：原子性（Atomicity，要么全做要么不做）、一致性（Consistency，永远从一个合法状态到另一个）、隔离性（Isolation，并发事务互不踩踏）、持久性（Durability，提交后断电也不丢）。这就是为什么银行转账、订单、库存永远住在关系库里。MySQL 撑起了全世界大多数 WordPress 站点，PostgreSQL 则是功能最硬核的那个。

三、扩展性瓶颈：当单机装不下整个世界

关系库的软肋在扩展。传统上它主要靠垂直扩展——换更强的 CPU、加更多内存。但当数据冲到十亿行、请求遍布全球，单台机器再贵也有天花板。水平分片（Sharding）能把数据切到多台机器，但跨片 JOIN、分布式事务的复杂度陡增，DBA 的头发就是这么没的。

这正是 NoSQL 在 2000 年代末爆发的历史背景：互联网公司要的是无限横向扩展加灵活 schema，愿意为此牺牲一点一致性。BASE 模型（Basically Available 基本可用、Soft state 软状态、Eventually consistent 最终一致）就是这种取舍的总结——系统优先保证永远能应答，哪怕数据暂时不一致。

当然，关系库也没坐以待毙。NewSQL 阵营（如 CockroachDB、TiDB）试图把 SQL 的 ACID 与水平扩展结合起来，让关系库也能像 NoSQL 一样横向铺开；PostgreSQL 自身则靠 Citus 扩展做分布式分片。所以扩展的瓶颈正在被两端同时化解，世界没有谁彻底取代谁，而是在互相学习。

四、NoSQL 狂潮：Redis 的速度与 MongoDB 的自由

NoSQL 不是一个产品，而是一整个家族。其中两个最出圈的代表，正是 Redis 和 MongoDB。

五、Redis：内存里的闪电

Redis 是个基于内存的键值数据库，核心操作是按 Key 取 Value，延迟能做到亚毫秒级。它常年位居 DB-Engines 排行榜最流行内存数据库第一，从初创公司到全球最大平台都在用。它本职是缓存——把热点数据放内存，DB 压力骤减；但它早已不只是缓存：会话（Session）存储、购物车、限流计数器、排行榜（ZSET）、发布订阅（Pub/Sub）、消息流（Streams）甚至向量搜索，它都能干。简单说，凡是快字当头的场景，Redis 都是第一候选。

六、MongoDB：把 JSON 当祖宗供着

MongoDB 是文档数据库的老大，约占文档库市场 45% 的份额。它把数据存成类似 JSON 的 BSON 文档，字段可以嵌套、数组可以随便塞，不同记录的字段还能天差地别——你改个产品需求，不用跑痛苦的表结构迁移（Migration）。这对内容平台、商品目录、用户画像这类记录本身就像一篇文档的场景极其友好。代价是，一旦业务强烈依赖跨记录的复杂事务和引用完整性，文档库就不那么舒服了。

七、融合时代：PostgreSQL 的全能化

剧情在 2020 年代出现神转折：原本稳重老干部般的 PostgreSQL，靠扩展生态把 NoSQL 的活儿一点点抢了回来。

2014 年（PostgreSQL 9.4）加入的 JSONB 类型，让 PG 既能享受 MongoDB 式的灵活文档，又不丢 ACID 和 JOIN。Uber 在 2022 到 2023 年把部分原先用 MongoDB 存的 schemaless 数据迁回 PostgreSQL 加 JSONB；Notion 整款产品（页面、块、一切）都跑在 Postgres 加重度 JSONB 上；Instagram 从 2010 年第一天起就 All-in PostgreSQL。社区那句玩笑从灵活数据用 Mongo变成了没有特别理由就用 Postgres JSONB。

八、JSONB 与 pgvector：一个扩展吃掉十亿赛道

真正的降维打击发生在 2023 年 5 月 23 日：开发者 Andrew Kane 发布了 pgvector 0.4.0，一个约两千行的扩展，给 PostgreSQL 加上了向量类型和相似度检索（支持 IVFFlat、HNSW 等索引）。48 小时内 LangChain、LlamaIndex 就接了进来，Supabase、Neon、Vercel 纷纷一键开启。结果就是：搞 AI 应用（RAG、语义搜索）的创业者，原本要花大价钱养一个独立向量数据库（Pinecone、Weaviate、Milvus），现在直接在已有的 Postgres 里加个扩展就搞定，有人把每月向量账单从近 2000 美元砍到 180 美元。

如今 PG 的扩展货架还有：PostGIS（地理空间，Uber 也在用）、TimescaleDB（时序）、pgmq（消息队列）、Citus（分布式）。2025 年一项调研显示 PostgreSQL 采用率冲到约 55.6%，领先 MySQL 近 19 个百分点；Supabase 估值在 2025 年 10 月达到 50 亿美元，背后是 400 万开发者。一个数据库，正在变成后端操作系统。

九、极限性能：NVMe 与大内存如何榨干数据库

无论选哪种库，硬件都在重塑性能上限。NVMe SSD 把磁盘延迟压到微秒级、IOPS 推到数十万，让磁盘不再是瓶颈；大内存则让数据库把索引和热数据整张塞进 RAM，Redis 干脆全放内存。现代 Postgres 可以把 shared_buffers（共享缓冲区）开到几十 GB，配合连接池（PgBouncer）扛住高并发；MySQL 在简单读多写少场景下依旧轻快。

但老话一句：慢数据库十有八九是缺索引，不是选错库。把索引建对、把热数据放对介质，比追新潮重要得多。

十、现代生产栈：一个 Postgres 打天下还是混合阵型

说了这么多，一个很实际的问题是：我到底该用几个数据库？行业里有个越来越明显的趋势——小团队尽量用一个 Postgres 打天下。PG 通过扩展已经能覆盖搜索、队列、时序、地理、向量，少维护一个系统就少一堆胶水代码和故障点。Vercel 的 Guillermo Rauch 有句名言：一个数据库，就是整套技术栈了。

但超大规模或特殊场景仍要混合阵型：Postgres 当交易真相源，Redis 扛缓存和会话，对象存储（S3/MinIO）存大文件，必要时再上 ClickHouse 做分析、Neo4j 做图关系。关键不是追潮流，而是让每种数据落在最契合它访问模式的引擎上。先用 Postgres，遇到真实瓶颈再加专长数据库，这比一开始就堆五六个系统稳得多。

#数据库 #PostgreSQL #MySQL #Redis #MongoDB #NoSQL #pgvector