你为什么为你的应用选择那个数据库？
Source: Dev.to
一段关于简历驱动开发（Resume‑Driven Development）、“Google Scale” 幻想以及为什么我们最终总是使用 Postgres 的自白。
你倒了一杯新鲜的咖啡，砸响指关节，键入 mkdir my-next-billion-dollar-idea，然后……你僵住了。
你撞上了 持久化之墙。是时候选数据库了。说实话，在系统设计面试中给出的答案往往并不是你为副项目挑选数据库的 真实 原因。
如果我们百分之百诚实，大多数架构决策文档会写成：“我们选择 MongoDB 是因为首席开发者害怕 JOIN 语句”，或者 “我们选择 Cassandra 是因为想要有 Netflix 的感觉”。
但你必须做出实际的选择。下面我们来探讨挑选数据库的混乱决策树、我们自欺的谎言，以及如何在不掉眼泪的情况下选对数据库。
糟糕数据库决策的三大骑士
1. “Google Scale” 幻想
你正在为你的猫构建一个待办事项应用。现实中你只会有三个用户：你、你的伴侣以及你创建的测试账号。但你仍会这样想：
“但是分片怎么办？如果我的猫成了网红，我需要在 AWS us‑east‑1 的三个可用区都有写入可用性怎么办？”
现实检查： 你没有大数据，只有小数据。你的数据可以放进 RAM，甚至可以放进一个文本文件。不要为五年后可能出现的问题去优化，而是为下周二的交付去优化。
2. 简历驱动开发（RDD）
你在 Hacker News 上看到一个新的向量数据库。它是用 Rust 写的，logo 是一只酷炫的几何狐狸。你根本不知道向量嵌入是什么，但你知道如果把它写进简历，招聘者可能会误给你 20 万美元的报价。
现实检查： 无聊的技术能赚钱，刺激的技术会导致宕机。
3. “无模式” 陷阱
“我不想定义模式，我想快速迭代，打破常规。”
于是你选了文档存储。六个月后，你的数据库里 user_id 在一半文档里是字符串，另一半是整数，而在那个你疲惫的星期二创建的文档里则是 null。
现实检查： 你始终拥有模式。要么由数据库强制（好），要么由一堆 if (typeof x === 'undefined') 语句在业务代码中强制（坏）。
实际菜单：给迷茫者的指南
1. 关系型数据库（SQL）
竞争者：PostgreSQL、MySQL、MariaDB
氛围： 那个负责的老大哥，按时报税。
何时使用： 95 % 的情况。如果你的数据有关系（例如 Users → Orders → Items），就用 SQL。它保证 ACID 合规并强制结构。
人们回避的原因： 必须学习 SQL。
你应该使用的理由： SQL 是数据的通用语言。它会在宇宙热寂之前一直存在。
小技巧： 直接用 PostgreSQL。它已经支持 JSON Blob，所以基本上是“穿着风衣的关系型数据库 + NoSQL”。
2. 文档存储（NoSQL）
竞争者：MongoDB、Firestore、DynamoDB
氛围： 混乱的艺术家阁楼。把所有东西都扔进一堆，之后再整理。
何时使用：
- 原型开发，数据结构频繁变化。
- 数据真正以文档为中心（例如一篇博客文章把评论和标签都放在同一个对象里）。
- 读取密集型工作负载，只想拿到 ID 并立即得到一个巨大的 JSON Blob。
警告： 在非关系型数据库里存放关系型数据是地狱循环，只适合喜欢在业务代码里写嵌套循环的人。
3. 键值存储
竞争者：Redis、Memcached
氛围： 咖啡因滴注下的肾上腺素狂热者。
何时使用： 缓存、会话管理、排行榜。
不要把它当作： 主要的数据真相源。如果服务器重启导致 Redis 实例丢失——而你的用户账户正存放在那里……恭喜，你已经没有用户了。
4. 图数据库
竞争者：Neo4j、Amazon Neptune
氛围： 那块贴满红线的阴谋论布告板。
何时使用： 当 数据之间的关系 比数据本身更重要时——社交网络、欺诈检测环、推荐引擎。
数学原理： 如果你的 SQL 查询包含 14 条 JOIN，且执行时间达到 20 秒，你可能需要图数据库。
最终裁决
怎么选？下面是一个简易算法，帮你省去数周的调研时间：
- 你需要为 AI 应用在向量空间进行复杂搜索吗？ 使用向量数据库（Pinecone、Weaviate 或 pgvector）。
- 你的数据本身就是社交图谱吗？ 使用图数据库。
- 你有每秒 5000 万次写入来自 IoT 传感器吗？ 使用时序数据库。
- 除此之外的所有情况？ 使用关系型数据库。
“那到底选哪款关系型数据库？” 我听到你的提问。
选你最会部署的那一款。如果你对任何一种都不熟悉，就选 Postgres，每月 15 美元买个托管实例，然后去实现你的真实功能。
用户并不在乎你用了什么数据库，他们在乎登录按钮能正常工作。