MySQL vs PostgreSQL vs Supabase（数据库选型对比）
1. 先厘清：三者不是同类
- MySQL、PostgreSQL → 两个数据库引擎（平级竞品）。
- Supabase → Backend-as-a-Service 平台，底层就是 PostgreSQL，不是引擎。
- 所以正确拆法是两组对比：① MySQL vs PostgreSQL（选”发动机”）；② 裸 PostgreSQL vs Supabase（“发动机自己配”还是”连车带司机一起买”）。把 Supabase 直接和 MySQL 比，是苹果比橘子。
2. MySQL vs PostgreSQL（引擎层）
| 维度 | MySQL | PostgreSQL |
|---|---|---|
| 归属 | Oracle 所有，最流行的 Web 数据库 | 社区开源，对象关系型 |
| 哲学 | 简单、快、易上手 | 标准严格、极度可扩展 |
| 强项 | 读多写多的普通 CRUD、生态海量（LAMP） | 复杂查询、CTE/窗口函数、JSONB、自定义类型、扩展（PostGIS 地理、pgvector 向量/AI embeddings） |
| 弱项 | 高级 SQL/扩展能力弱一些 | 连接是”一连接一进程”，高并发要 pgbouncer 池化 |
| 适合 | 常规 Web 应用、不想操心 | 数据结构复杂、要地理/向量/严格 SQL、要自己造能力 |
3. Supabase 站在哪
- = 托管的 PostgreSQL + 一套开箱即用的后端：
- Auth（GoTrue，登录/鉴权）、自动 REST + GraphQL API（PostgREST，直接把表变接口）、Realtime（逻辑复制 + WebSocket 实时推送）、Storage（对象存储）、Edge Functions（Deno）、RLS 行级安全做授权。
- 你写 SQL 操作的仍是 Postgres——“用 Supabase”等价于”用 PostgreSQL”，它送的是后端胶水 + 即时 API，让你不用自己撸 auth/CRUD 服务。
- 定位：Firebase 的开源替代品（Firebase 用 NoSQL Firestore，Supabase 用 SQL Postgres）。可自托管，也有云服务。
一句话：选 MySQL vs PostgreSQL 是选发动机；选 裸 Postgres vs Supabase 是发动机自己配，还是连车带司机一起买。
4. 怎么选
- MySQL：常规网站 CRUD、熟悉、主机商到处支持、不需要花活。
- PostgreSQL：要复杂查询 / JSONB 与关系混合 / 地理(PostGIS) / 向量检索(pgvector) / 想自己扩展。
- Supabase：想直接拿到”数据库 + 登录 + API + 实时”，不想自建后端；尤其 TS/JS 应用、独立开发、AI 应用（pgvector + embeddings 一条龙）。
5. 常见误区
- ❌ “Supabase 是另一种数据库” → 它是 Postgres 加后端平台；用 Supabase 就是在用 PostgreSQL。
- ❌ “PostgreSQL 更高级就该都用 PG” → 简单 CRUD、极致读性能、生态成熟度，MySQL 仍合适；选型看需求不看病。
- ❌ “Supabase 只适合小项目” → 底层是完整 Postgres + RLS，能撑生产；但高并发连接仍需池化（pgbouncer）。
- ❌ “MySQL 不能存 JSON” → 5.7+ 有 JSON 类型，只是 PG 的 JSONB 更原生（可建 GIN 索引等）。
6. 延伸阅读 / 关联概念
- postgres.md — PG 对象关系型、pgvector 兼当向量库的细节
- sqlite-turso.md — 嵌入式 SQLite vs client-server(MySQL/PG) 的边界
- sql-rag.md — 把 SQL 库当 RAG 检索源（Text2SQL）
- schema.md — schema 与 MCP 工具 schema 对比