一个 Supabase project, 6 个 schema, 6 个完全不同的项目. 这个架构跑了一年多, 聊聊利弊
独立开发者最容易踩的坑之一, 是给每个新项目单独开一套基础设施. 项目多了以后, 大部分时间花在管理基础设施上, 而不是写代码.
这篇聊一个我做了很久才下定决心的决策: 把所有项目的数据库统一到一个 Supabase project 里, 用不同的 schema 隔离.
方案对比
方案 A: 每个项目独立数据库
完全隔离, 但 6 个 Pro plan = $150/月, 加上管理 6 套连接配置, 太重.
方案 B: 自建 PostgreSQL
成本最低, 但备份, 安全, 监控全要自己搞. 数据库运维是我最不想碰的东西.
方案 C: 一个 Supabase + 多 schema
PostgreSQL 原生支持 schema, 相当于数据库内部的命名空间. $25/月, 一份钱, 六个项目用.
我选了方案 C
核心原因: 成本 ($25 vs $150), 管理简单 (一个 dashboard), PostgreSQL schema 天然支持隔离.
6 个 Schema 的组织
xhs | 小红书发布器 | ~8 | 小 |
feedsync | RSS 内容同步 | ~6 | 中 |
postiz | 社交媒体管理 | ~10 | 中 |
mail | StellarMail | ~12 | 大 |
twitter_publisher | Twitter 发布 | ~5 | 小 |
x_monitor | X.com 监控 | ~5 | 中 |
每个 schema 完全独立: 建表时指定 schema, Supabase client 通过
schema 选项指定, RLS 策略在 schema 级别配置.实际体验
好的方面: 一年多下来确实省心. 6 个项目一个地方管, 一份账单. 性能完全够用, 总数据量 2-3GB.
需要注意: 连接数共享, 备份是整个数据库一起, 单点故障风险存在但可接受.
为什么不选其他
- Firebase: NoSQL, 迁移成本极高, 不想被锁定
- PlanetScale: 取消免费版, 最低 $39/月, MySQL 而非 PostgreSQL
- Neon: 不错的 PostgreSQL serverless, 但 Supabase 提供了更全套服务 (Auth, Storage, Edge Functions)
- 自建: 运维成本太高
决策框架
- 先算账: 多少个项目, 各方案月成本
- 评估隔离需求: 是否有数据安全隔离的硬性要求
- 评估运维能力: 自己管的时间成本 vs 托管服务的费用
- 选择迁移成本最低的方案: 优先选标准技术 (SQL > NoSQL)
- 预留扩展空间: 方案应该支持未来拆分
Made with Bullet