本文最后更新于 2026年5月15日。
你的推测只对了一半。
“Supabase 搭建起来占内存”是事实，但“增加多个网站内存占用增加较少”以及“20个网站两者占用可能一样”的结论在自部署（Self-hosted）场景下是不成立的。
实际情况恰恰相反：在自部署环境下，如果你要搭建 20 个独立的网站/项目，使用 Supabase 会极其消耗内存，成本远高于 Directus。
下面为你详细拆解其中的原因：
❌ 为什么 Supabase 增加多个项目并不省内存？
很多人误以为 Supabase 像一个 Apache 或 Nginx 服务器一样，可以在一个实例里轻松跑无数个互不干扰的网站。但实际上，Supabase 的架构决定了它并不是这样工作的：
- 一套 Supabase = 一个独立项目
Supabase 是由十几个微服务（PostgreSQL, Kong, GoTrue, Realtime 等）组成的庞大集合。当你自部署一套 Supabase 时，你实际上是在启动这一整套微服务集群，这也就是为什么它起步就需要 4GB 甚至更多内存的原因。 - 无法简单共享底层组件
在官方托管版中，多个用户确实共享底层的物理资源。但在自部署时，如果你想让这 20 个网站的数据库、用户体系、API 权限完全隔离（通常商业项目都需要隔离），你就需要部署 20 套独立的 Supabase 实例。 - 内存占用是线性叠加的
假设一套最精简的 Supabase 实例勉强运行需要 2GB – 4GB 内存，那么搭建 20 个独立网站就需要 20 套这样的实例。这意味着你需要准备 40GB – 80GB 的内存，这在普通服务器上是不可能完成的任务。即使你尝试强行在一个 PostgreSQL 库里为 20 个网站建 20 个不同的库，你依然面临认证（Auth）、实时（Realtime）和存储（Storage）服务的多租户隔离难题，配置难度极高且极易产生数据冲突。
✅ 为什么 Directus 搭建 20 个网站反而更省内存？
Directus 的定位与 Supabase 完全不同，它本质上是一个无头 CMS（内容管理系统），类似于 WordPress，但更加现代化和轻量。
- 单实例多项目支持
Directus 只需要启动一个 Node.js 应用实例（通常几百 MB 到 1GB 内存就足够流畅运行）。在这一个 Directus 实例中，你可以创建无数个“项目（Collections）”，或者连接同一个数据库里的不同表来服务你的 20 个网站。 - 共享基础服务
这 20 个网站可以共享同一套 Directus 的管理后台、API 接口层和用户权限系统。虽然它们的数据可以通过权限隔离开，但它们不需要各自拥有一套独立的后端微服务。 - 极低的边际成本
用 Directus 搭建第 2 个、第 20 个网站时，你几乎不需要额外增加任何内存开销。只要底层的 PostgreSQL 或 MySQL 数据库撑得住，Directus 应用本身的内存占用基本维持不变。
⚔️ 20 个网站场景下的直观对比
为了让你更清晰地看到差异，我们可以做一个极限二选一的压力测试：
维度 自部署 Supabase (20个独立项目) 自部署 Directus (20个项目共用)
架构模式 20 套独立的微服务集群 1 个 Node.js 应用实例
预估总内存 40GB – 80GB+ (极难实现) 1GB – 2GB (非常轻松)
运维复杂度 极高（需管理 20 套升级、备份、网络） 极低（只需维护 1 个应用）
适用场景 20 个完全不相关的大型 SaaS 产品 20 个企业官网、博客、内容展示站
💡 总结与建议
- 如果你想在一台服务器上低成本地跑 20 个网站（如企业官网、个人博客、小型商城）： 绝对不要用自部署的 Supabase。请选择 Directus，甚至传统的 WordPress，它们才是为这种“单机多站”场景设计的，一台 2核4G 的普通服务器就能轻松搞定。
- 什么时候用 Supabase？ 当你有 1-2 个核心业务非常复杂、对实时性要求高、且不想写后端的 App 或 SaaS 平台时，Supabase 才是神器。如果是这种少量项目，直接使用 Supabase 官方提供的免费或付费云服务即可，完全不需要自己花钱买服务器去折腾那 4GB 内存的门槛。