数据层选型对比
前端接触数据库和后端服务时，最常见的困惑不是“语法怎么写”，而是“到底该选哪类方案”。
先按类型分
关系型数据库
- MySQL
- PostgreSQL
适合数据结构稳定、关系明确、事务要求高的场景。
文档型数据库
- MongoDB
适合结构变化频繁、嵌套文档多、早期迭代快的场景。
BaaS / 云服务
- Supabase
- Upstash
适合快速搭后端能力，或者在 Serverless / Edge 场景下减少基础设施负担。
快速对比
| 方案 | 更适合什么场景 | 优点 | 注意点 |
|---|---|---|---|
| MySQL | 传统业务系统、后台管理、订单类数据 | 生态成熟、资料多、维护经验丰富 | 复杂 JSON 场景不如 PostgreSQL 自然 |
| PostgreSQL | 复杂查询、类型丰富、需要更强扩展能力 | JSONB、索引、扩展能力强 | 学习曲线比 MySQL 稍陡 |
| MongoDB | 文档结构变化快、原型迭代快 | 模型灵活、嵌套结构自然 | 关系和事务设计要更谨慎 |
| Supabase | 前端主导的中小型产品、认证和实时能力一起上 | 一站式、上手快、和 PostgreSQL 贴得近 | 权限和 RLS 需要认真设计 |
| Upstash | 限流、缓存、队列、Edge 场景 | HTTP 接口天然适合 Serverless / Edge | 不适合作为所有业务数据的主存储 |
一些实际判断
- 做常规业务系统：MySQL / PostgreSQL 优先
- 需要更强 SQL 能力和扩展性：PostgreSQL 优先
- 需要灵活文档结构：MongoDB 可以考虑
- 需要快速把认证、实时、存储一起搭起来：Supabase 很合适
- 需要限流、缓存、向量检索、Edge 友好能力：Upstash 更顺手
常见误区
- 把缓存服务当主数据库来用
- 因为“开箱即用”就忽略权限设计
- 没分清业务主数据、缓存数据、搜索数据各自的边界