Marico's space

数据库选型这事，真没那么简单。市面上流传的那些"经验法则"——"正经项目用 PostgreSQL"、"Schema 经常变就用 MongoDB"、"大家都用 MySQL"——每句话都有点道理，但靠它们做不了实际项目的决策。

数据库不只是"存数据的地方"。它决定了你的应用怎么处理业务规则、报表查询、扩容方案、开发流程、问题排查，以及以后产品怎么迭代。一旦产品跑起来了再做数据迁移和清洗，代价往往很高。所以在一开始就想清楚这件事，很重要。

我们团队（Paradane）做过定制软件、电商平台、SaaS 产品、内部工具、API 对接和自动化系统各种项目。这篇说说我自己在选型时实际用的思路。

从业务问题本身开始

比较数据库之前，先把产品的数据结构特征定义清楚：

• 数据之间的关系是不是产品的核心？
• 报表和数据分析有多重要？
• 需不需要强一致性？
• 记录是不是文档式的、结构经常变化？
• 非技术人员会不会需要查看或导出数据？
• 要对接哪些已有系统？

最好的数据库，通常是让核心业务逻辑最容易表达、最容易维护的那个。

PostgreSQL：关系型产品的默认选择

PostgreSQL 是我们很多项目的首选，因为它在关系型数据完整性之外，还有足够的灵活性支持现代产品开发。

它适合这类场景：

• 用户、团队、角色、权限体系
• 订单、发票、支付、订阅
• 库存、目录、履约流程
• 审计日志、合规要求
• 仪表盘和报表查询
• 复杂筛选和搜索需求

最大的优势是"可信"。约束、事务、索引、成熟的 SQL 行为，这些能防止数据进入无效状态。

举个例子：如果每张发票必须属于某个客户，且发票号在同一账户下必须唯一，PostgreSQL 可以直接这样约束：

CREATE TABLE invoices ( id uuid PRIMARY KEY, account_id uuid NOT NULL REFERENCES accounts(id), customer_id uuid NOT NULL REFERENCES customers(id), invoice_number text NOT NULL, total_cents integer NOT NULL CHECK (total_cents >= 0), status text NOT NULL CHECK (status IN ('draft', 'sent', 'paid', 'void')), UNIQUE (account_id, invoice_number)
);

应用层当然也要做数据校验，但数据库是最后一道防线。系统会被 API 请求、管理后台、后台任务、数据导入、Webhook 各种渠道触发，这道防线就很重要了。

PostgreSQL 让人意外的地方

PostgreSQL 不只是一台传统的关系型数据库。它处理 JSON 数据很顺手、支持全文搜索、有地理空间数据的扩展、还能实现队列模式（谨慎使用的话）。

这种灵活性意味着团队早期不需要引入额外的中间件。一个 SaaS MVP 用 PostgreSQL、合理的 Schema、加上几个精心设计的索引，往往能走很远。

当你希望只有一个可靠的核心数据库、同时产品预期会越来越复杂的时候，选 PostgreSQL。

MongoDB：适合文档密集型、结构多变的场景

MongoDB 最强的地方是：当数据的自然单元是文档、且不同记录的结构差异很大时。

它可能适合这些情况：

• 内容管理系统有各种灵活的内容块
• 事件采集，不同来源的 payload 格式不一样
• 商品目录，各品类的属性差异很大
• 原型阶段，数据模型还在摸索
• 应用场景以嵌套文档为主，关系表为辅

商品目录是个典型例子。一件家具、一颗宝石、一个软件许可证、一件服装，它们可能共享几个字段，但属性差异巨大。文档模型处理这种情况会更自然。

{ "name": "锡兰蓝宝石", "category": "宝石", "attributes": { "carat": 2.1, "origin": "斯里兰卡", "cut": "椭圆形", "certification": "GIA" }
}

如果过早把所有可能的属性硬塞进关系表的列里，Schema 会变得很乱。MongoDB 能减少这种摩擦——前提是产品真的需要这种灵活的文档结构。

MongoDB 的取舍

代价是：灵活性把责任推给了应用层代码和团队纪律。如果每个文档长得都不一样，代码必须处理这种现实。业务部门问跨字段、跨关系的报表问题时，也会更麻烦。

MongoDB 不是什么 Schema 设计的捷径。它依然需要索引、验证规则、迁移策略和开发规范。没有这些，数据库最后会变成一抽屉乱七八糟的 JSON。

只有当文档灵活性是真实的产品需求时，才选 MongoDB。不是因为懒得设计 Schema。

MySQL：成熟、常见，依然是个好选择

MySQL 在很多 Web 应用场景下仍然是很好的选择。它支持广泛、很多开发者熟悉、在各种主机平台、CMS 生态、电商工具里扎得很深。

它往往是实际的好选择当：

• 客户已经在跑 MySQL
• 应用深度集成 WordPress、WooCommerce、Magento 或传统 PHP 系统
• 团队有丰富的 MySQL 运维经验
• 主机环境约束偏向 MySQL
• 数据模型是关系型的，但不复杂

对于很多企业网站和运营系统，MySQL 完全够用。问题不是它能不能用，而是它能不能给你的项目长期最好的开发体验。

MySQL 的取舍

对比 PostgreSQL，MySQL 在某些高级约束、JSON 工作流和分析查询上会显得表达力不足。但这不意味着它差，而是团队应该诚实面对项目需求。

如果客户有一个 WooCommerce 店铺，需要定制报表、对接第三方系统或后台自动化，MySQL 可能已经在这个环境里了。这时候围绕已有的数据库构建系统，可能比引入新数据库更划算。

当生态契合和运维熟悉度比高级关系特性更重要时，选 MySQL。

决策框架

一个简单的选型思路：

选 PostgreSQL 当：

• 数据完整性是关键的
• 数据关系是核心的
• 报表和分析很重要的
• 预期产品复杂度会增长
• 需要强约束和事务支持
• 希望一个数据库能很好地满足多种需求

选 MongoDB 当：

• 记录天然是文档形态的
• 结构在不同记录间差异很大
• 嵌套数据比关联查询更重要
• 产品模型在快速迭代
• 灵活属性是核心需求

选 MySQL 当：

• 项目依赖 MySQL 主导的生态
• 团队或客户已经很熟悉 MySQL 并能良好运维
• 主机或遗留系统约束指向它
• 关系模型简单直接
• 兼容性比高级特性更重要

常见误区：追潮流而不是考虑维护

数据库的讨论经常被框在"新潮 vs 老旧"、"SQL vs NoSQL"、"可扩展 vs 不行"这种叙事里。这种框架通常没什么用。

更好的问题是：两年后谁来维护这个系统，他们需要多快搞懂系统现状？

选数据库应该让未来排查问题更容易。应该让无效状态更难出现。应该支持业务实际会要的那些报表。应该匹配团队的部署和备份能力。

早点考虑迁移策略

每个成功的产品最终都会改动数据模型。从一开始就建立迁移规范：

• 迁移脚本放版本控制
• 用真实数据量测试迁移
• 破坏性改动前先备份
• 在迁移注释里写清楚假设
• Schema 改动和有风险的数据转换尽量分开

这也是我们为什么对很多业务应用喜欢关系型数据库的原因之一。Schema 改动是显式的、可审查的。但同样的规范对 MongoDB 也适用——文档结构也在演进，老记录也需要处理。

最后

大多数项目失败，不是因为 PostgreSQL、MongoDB 或 MySQL 客观上不够用。而是数据库没匹配业务模型、团队跳过了约束、或者没人提前规划报表、迁移和运维。

如果你在做一个 SaaS 产品、电商系统、内部平台或深度集成的应用，数据库选型值得比"随便选一个"更多思考。在 Paradane，我们帮团队基于可维护性做架构决策，围绕清晰的取舍而不是炒作来构建产品。