Directus vs Supabase 2026 对比：选择你的后端
Directus vs Supabase in 2026: 选择你的后端
在过去三年中，我在 Directus 和 Supabase 上都发布过项目。每当有人问我"我应该选择哪一个？"时，我的回答都是一样的：这取决于你实际在构建什么。这不是逃避问题——这两个工具确实服务于不同的主要目的，尽管它们在令人惊讶的方式上有重叠。Directus 是一个无头 CMS，将任何 SQL 数据库包装在一个漂亮的管理 UI 和 REST/GraphQL API 中。Supabase 是一个建立在 PostgreSQL 上的 Firebase 替代品，为你提供身份验证、实时订阅、存储和边缘函数。重叠的地方？两者都给你一个数据库，两者都给你一个 API，两者都有用于管理数据的仪表板。但是每一个背后的哲学从根本上是不同的，而这种哲学塑造了你下游的每一个决定。
让我带你走过我用两者在生产中构建学到的东西。
目录
哲学和核心身份
Directus 称自己为"数据平台"，但让我们说实话——它的核心是一个无头 CMS。它获取你现有的 SQL 数据库（PostgreSQL、MySQL、MariaDB、MS SQL、SQLite、Oracle、CockroachDB）并在顶部分层一个内容管理界面。关键见解：Directus 不拥有你的数据模式。你可以将其指向现有数据库，它会自动内省表和关系。如果你已经有一个数据库并需要一个管理层，这是非常强大的。
Supabase 是一个后端即服务（BaaS）。它是 PostgreSQL 加上附加功能：身份验证、文件存储、实时订阅、边缘函数和用于 AI 工作负载的向量嵌入。Supabase 假定你正在构建一个应用程序，而不是管理内容。仪表板是为开发人员设计的，而不是为内容编辑设计的。
这种哲学上的差异比任何功能比较都更重要。如果你正在构建一个内容驱动的网站，编辑需要发布博客文章、管理媒体和预览更改——Directus 就是为此而设计的。如果你正在构建一个 SaaS 应用程序，其中用户注册、存储数据并实时交互——Supabase 就是为此而设计的。
但大多数真实项目都不是那么简洁。这就是事情变得有趣的地方。
数据库和数据建模
Directus
Directus 使用"数据库优先"的方法。你通过 Directus UI 或直接在数据库中定义你的模式——两者都可以。管理应用程序根据你的模式自动生成表单、关系和验证。想要一个 many-to-many 关系在 articles 和 tags 之间？创建结合表（或让 Directus 创建它），管理 UI 自动呈现一个漂亮的标签选择器。
我欣赏的一件事：Directus 不会在你的表上创建自己的抽象层。你的表名、列名和关系完全是你定义的。系统表（以 directus_ 为前缀）与你的数据相邻但不干扰它。
2026 年支持的数据库：
- PostgreSQL 12+
- MySQL 8+
- MariaDB 10.5+
- MS SQL 2019+
- SQLite 3+
- CockroachDB 22+
- Oracle 19c+
Supabase
Supabase 是 PostgreSQL。就这样。你获得一个完整的 Postgres 实例，扩展包括 PostGIS、pgvector、pg_cron 和数百个其他的。模式管理通过仪表板的 SQL 编辑器、它们的表编辑器 UI 或通过 Supabase CLI 的迁移进行。
Supabase 中的迁移工作流已经显著成熟。CLI 生成迁移文件，你可以使用 supabase db diff 来捕获通过仪表板进行的模式更改。在 2026 年，他们还添加了分支——数据库分支让你在合并到生产之前以隔离的方式测试模式更改。
-- Supabase 迁移示例
create table public.articles (
id uuid default gen_random_uuid() primary key,
title text not null,
slug text unique not null,
content jsonb,
published_at timestamptz,
author_id uuid references auth.users(id),
created_at timestamptz default now()
);
alter table public.articles enable row level security;
create policy "Published articles are viewable by everyone"
on public.articles for select
using (published_at is not null and published_at <= now());
行级安全 (RLS) 模型既是 Supabase 的超级力量，也是其最陡峭的学习曲线。稍后再详谈。
| 功能 | Directus | Supabase |
|---|---|---|
| 数据库引擎 | PostgreSQL、MySQL、MariaDB、MS SQL、SQLite、CockroachDB、Oracle | 仅 PostgreSQL |
| 模式管理 | GUI + 直接 SQL | GUI + SQL 编辑器 + CLI 迁移 |
| 数据库分支 | 未内置（使用单独的实例） | 是（本地支持，自 2024 年末以来） |
| 扩展 | 取决于选择的数据库 | 60+ Postgres 扩展 |
| 向量/AI 支持 | 通过扩展 | pgvector 内置 |
| 直接数据库访问 | 始终完全访问 | 始终完全访问 |
API 层比较
Directus API
Directus 从你的模式自动生成 REST 和 GraphQL API。REST API 遵循可预测的模式：
# 获取所有文章及作者关系
GET /items/articles?fields=*,author.name&filter[status][_eq]=published&sort=-published_at&limit=10
过滤系统很富有表现力。你可以进行嵌套关系过滤、聚合，甚至地理查询。SDK 将所有这些很好地包装起来：
import { createDirectus, rest, readItems } from '@directus/sdk';
const client = createDirectus('https://your-instance.com').with(rest());
const articles = await client.request(
readItems('articles', {
fields: ['*', { author: ['name', 'avatar'] }],
filter: { status: { _eq: 'published' } },
sort: ['-published_at'],
limit: 10,
})
);
Directus 中的 TypeScript SDK（截至 2026 年的当前稳定版 11）在类型推断方面有了很大改进，尽管你仍然需要从你的模式生成类型以获得完整的类型安全性。
Supabase API
Supabase 通过 PostgREST 生成 REST API，并提供一个感觉更像 ORM 的 JavaScript 客户端库：
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);
const { data: articles, error } = await supabase
.from('articles')
.select('*, author:profiles(name, avatar_url)')
.eq('status', 'published')
.order('published_at', { ascending: false })
.limit(10);
Supabase 不提供开箱即用的 GraphQL。他们曾经有 pg_graphql，现在仍可作为扩展使用，但主要的 DX 是他们的 JS 客户端和 REST API。说实话？当使用 Supabase 时，我不会想念 GraphQL。带有关系联接的 select 语法覆盖了 95% 的用例。
Supabase 领先的一个领域：通过 WebSocket 的实时订阅和用于服务器端逻辑的边缘函数。Directus 有 Flows（他们的自动化引擎），但这与拥有完整的无服务器函数运行时不同。
内容管理体验
这是 Directus 完全主导的地方。这甚至不接近。
Directus 的管理应用程序是为内容团队设计的。你可以获得：
- 自定义布局：看板、日历、地图、用于集合浏览的分割视图
- WYSIWYG 和块编辑器：Directus 11 中的块编辑器确实很好
- 翻译支持：内置的 i18n，带并排翻译界面
- 修订历史：完整的内容版本控制，带差异视图
- 实时预览：配置预览 URL，以便编辑可以在发布前看到更改
- 粒度权限：基于角色的访问，直至各个字段
- 自定义仪表板：用于内容团队的分析和概览面板
Supabase 的表编辑器是......一个表编辑器。对于想要其数据库的 GUI 的开发人员来说很棒。对于需要更新主页英雄部分的营销团队来说非常糟糕。如果你正在构建一个内容驱动的网站，你的编辑将直接接触后端，Directus 默认获胜。
我见过团队尝试在 Supabase 之上构建一个自定义管理 UI 来进行内容编辑。它有效，但你基本上是从头开始构建 CMS。这是 Directus 在第一天给你的工作量数个月。
如果你正在寻找为你的网站设置一个适当的无头 CMS，我们的团队定期在 headless CMS projects 中与 Directus 一起工作——它是我们对内容丰富的网站的首选推荐之一。
身份验证和授权
Supabase 认证
Supabase Auth 是一个功能完整的身份验证系统。电子邮件/密码、魔法链接、OAuth（Google、GitHub、Apple 等）、电话/SMS 和 SAML SSO 都内置。它直接与 PostgreSQL 的行级安全集成，这意味着你的身份验证规则存在于数据库本身。
-- 仅允许用户读取自己的个人资料
create policy "Users can view own profile"
on profiles for select
using (auth.uid() = id);
-- 允许用户更新自己的个人资料
create policy "Users can update own profile"
on profiles for update
using (auth.uid() = id);
一旦你理解了这个模型，它就很优雅了，但 RLS 政策可以快速变得复杂。调试为什么查询因缺少政策而返回空结果是你学会接受的那些乐趣之一。
Directus 认证
Directus 为自己的管理员用户处理身份验证，也支持通过 OpenID Connect、SAML、LDAP 和 OAuth2 的外部 SSO。对于前端应用程序用户，你通常会使用 Directus 的用户系统和自定义角色。
Directus 中的权限模型是 GUI 驱动的。你创建角色，然后对于每个角色，你配置每个集合的 CRUD 权限，可选择带有字段级和项目级规则。它比 RLS 政策更直观，可以说更容易推理，但对于复杂的应用逻辑不够灵活。
对于终端用户身份验证是主要关注的应用程序（想想 SaaS 应用），Supabase 的身份验证系统明显更成熟。对于管理内容团队访问权限，Directus 的角色系统更合适。
实时功能
Supabase 的实时引擎是生产就绪的，处理存在、广播和数据库更改侦听器：
const channel = supabase
.channel('articles')
.on('postgres_changes', {
event: 'INSERT',
schema: 'public',
table: 'articles',
}, (payload) => {
console.log('New article:', payload.new);
})
.subscribe();
这对于聊天应用、协作工具、实时仪表板和通知系统来说真的很有用。
Directus 添加了 WebSocket 支持，并通过其 GraphQL 订阅端点提供实时订阅。它有效，但不是同样的成熟度。Directus Realtime 对"当内容更改时通知我"的场景很好，但不是为高频协作应用程序构建的。
自托管和基础设施
两个工具都是开源的，可以自托管。
Directus 是一个 Node.js 应用程序，分布为 npm 包和 Docker 镜像。自托管很直接——指向你的数据库，配置环境变量，你就在运行了。我已在 Railway、Fly.io、AWS ECS 和普通 VPS 实例上部署过它，没有问题。
Supabase 自托管更复杂。完整堆栈包括 PostgreSQL、PostgREST、GoTrue（身份验证）、Realtime、Storage、Kong（API 网关）和 Studio 仪表板。他们的 Docker Compose 设置对开发有效，但生产自托管需要更多的操作知识。除非他们有特定的合规要求，否则大多数团队选择 Supabase 的托管平台。
| 方面 | Directus 自托管 | Supabase 自托管 |
|---|---|---|
| 复杂性 | 低-中（单个 Node.js 应用 + 数据库） | 高（7+ 服务） |
| Docker 支持 | 官方镜像，简单 | Docker Compose，复杂 |
| 最小资源 | 1 vCPU，1GB RAM | 4 vCPU，8GB RAM（所有服务） |
| 社区指南 | 广泛 | 增长但不够成熟 |
| 托管替代方案 | Directus Cloud | Supabase 平台 |
2026 年定价明细
让我们谈谈钱。这些是截至 2026 年初的当前公布价格。
Directus Cloud
| 计划 | 价格 | 包括 |
|---|---|---|
| Community（自托管） | 免费 | 一切，自管理 |
| Standard | $99/月 | 1 个项目，100K API 请求，5GB 资产 |
| Professional | $399/月 | 自定义域，更多资源，优先支持 |
| Enterprise | 定制 | SSO、SLA、专用基础设施 |
Supabase 平台
| 计划 | 价格 | 包括 |
|---|---|---|
| Free | $0 | 500MB 数据库，1GB 存储，50K 认证用户，500K 边缘函数调用 |
| Pro | $25/月 | 8GB 数据库，100GB 存储，100K 认证用户，2M 边缘函数调用 |
| Team | $599/月 | 优先支持，SOC2，每日备份，28 天日志保留 |
| Enterprise | 定制 | SLA、专门支持、自定义合同 |
价格差异很大。Supabase 的免费套餐确实可用于副业项目和 MVP。Directus Cloud 在 $99/月处的入场点对于实验来说很陡峭——但在 $5/月 VPS 上自托管 Directus 对于小项目完全有效。
对于正在构建应用的初创公司，Supabase 的 $25/月 Pro 计划提供了很多。对于运行内容丰富网站的企业，Directus 自托管加上托管 PostgreSQL 实例可能总共花费 $20-50/月。
开发者体验
我构建很多 Next.js projects 和 Astro sites，所以框架集成对我来说很重要。
Directus DX
- TypeScript SDK 很好，每个版本都在改进
- 模式类型可以从你的实例生成
- 扩展系统用于自定义端点、钩子、面板和接口
- Flows（视觉自动化）可以替代简单的后端逻辑
- 管理应用程序可以通过自定义模块和布局定制
- 资产交付 API 内置的图像转换
Supabase DX
- TypeScript 类型从你的模式自动生成（
supabase gen types typescript） - 本地开发配合
supabase start（在 Docker 中运行所有内容） - 边缘函数（基于 Deno）用于服务器端逻辑
- 内置的带有 pgvector 的向量搜索用于 AI 功能
- CLI 驱动的工作流，带迁移、分支和 CI/CD
- Vercel/Netlify 集成用于环境变量同步
两者都有可靠的文档。Supabase 的文档特别组织良好，带有特定框架的指南（Next.js、Nuxt、SvelteKit、Flutter 等）。Directus 的文档很全面但有时滞后于最新的 SDK 变化。
何时使用各个
在广泛使用两者后，这是我的决策框架：
选择 Directus 当：
- 内容编辑需要一个精美的管理界面
- 你正在构建营销网站、博客或编辑平台
- 你需要多语言内容管理
- 你现有的数据库需要管理 UI
- 内容工作流（草稿、审查、批准）很重要
- 你想使用 MySQL、MariaDB 或另一个非 PostgreSQL 数据库
选择 Supabase 当：
- 你正在构建一个面向用户的应用（SaaS、市场、社交）
- 你需要身份验证和用户管理
- 实时功能是核心要求
- 你想要用于服务器端逻辑的边缘函数
- AI/向量搜索是你路线图的一部分
- 你想要从想法到部署应用的最快路径
同时使用两者当：
这并不疯狂。我构建过 Supabase 处理用户身份验证、应用数据和实时功能的系统，而 Directus 管理营销网站内容、博客和文档。他们可以共享相同的 PostgreSQL 实例或使用单独的数据库。关注点的分离实际上使架构更清洁。
如果你试图为你的项目弄清楚正确的后端架构，这从字面上是我们团队所做的——欢迎 reach out 并讨论你的具体情况。
常见问题
Directus 能否替代 Supabase 作为网络应用的后端？ 部分地。Directus 给你一个数据库 API 和用户管理，所以对于简单的 CRUD 应用，它可以工作。但你会错过 Supabase 的内置身份验证系统、实时订阅、边缘函数和文件存储服务。Directus 针对内容管理进行了优化，而不是应用程序后端工作负载。对于大多数操作内容的简单应用，Directus 很好。对于任何具有用户身份验证流、实时功能或复杂服务器端逻辑的东西，你需要 Supabase 或类似的 BaaS。
Supabase 作为无头 CMS 好吗？ 它可以充当一个，但需要大量自定义工作。你需要为内容编辑构建自己的管理界面、单独处理图像转换、手动实现内容版本控制，并创建自己的预览系统。团队已经用 Supabase + 自定义 React 管理面板等工具完成过此操作，但你正在重新发明 Directus（或 Strapi、或 Payload）开箱即用给你的东西。如果内容管理是你的主要需求，使用专门的无头 CMS。
哪个对 Next.js 应用程序更好？
两者都与 Next.js 集成良好。Supabase 有官方的 Next.js 助手（@supabase/ssr），在服务器组件和中间件中处理身份验证 cookie 管理。Directus 也与 Next.js 配合得很好——你通过服务器组件中的 SDK 获取数据，并为性能使用 ISR 或 SSG。对于带有博客的营销网站，我会将 Next.js 与 Directus 配对。对于带有用户账户的 SaaS 应用，将 Next.js 与 Supabase 配对。我们在 Next.js development practice 中深入讨论了这一点。
我能免费自托管 Directus 和 Supabase 吗？ 是的。两者都是开源的，具有宽松的许可证（Directus 使用 BSL 1.1 许可证，在 3 年后转换为 Apache 2.0；Supabase 对大多数组件使用 Apache 2.0）。Directus 更容易自托管——它是一个单一的 Node.js 应用。Supabase 自托管需要运行多个服务（PostgreSQL、PostgREST、GoTrue、Realtime、Storage、Kong）。对于 Supabase，大多数开发人员使用托管平台并为自己节省操作开销。
Directus 和 Supabase 如何处理文件存储和媒体？ Directus 有一个内置的资产管理系统，可以进行即时图像转换（调整大小、裁剪、格式转换）。你通过管理 UI 或 API 上传文件，并通过 URL 参数请求转换版本。Supabase Storage 是一个 S3 兼容的文件存储服务，具有基于 RLS 的访问控制。它很好地处理上传和下载，但没有内置的图像转换——你需要将其与 Imgix、Cloudinary 或 Supabase 自己的图像转换（在 2025 年以测试版推出）这样的服务配对。
性能和可伸缩性呢？ Supabase 的基础设施建立在 AWS 上，通过 Supavisor 进行连接池，可以处理大量流量。他们的 Pro 计划数据库可以扩展到 64GB RAM 实例。Directus 的性能在很大程度上取决于你的托管设置和数据库。通过适当的缓存（Redis、CDN），Directus 处理高流量很好，但你负责基础设施。在基准测试中，两者都可以用适当的资源处理每秒数千个请求。瓶颈几乎总是数据库，而不是 API 层。
对于拥有非技术成员的团队，Directus 或 Supabase 更好？ Directus，毫无疑问。其管理界面是为非开发人员设计的。你可以创建自定义仪表板、设置内容批准工作流并按角色限制访问——全部无需编写代码。Supabase 的仪表板是一个开发人员工具。你的营销团队不会编写 SQL 来更新登陆页面。如果非技术团队成员需要管理数据，Directus 的 UI 是正确的选择。
我以后可以从一个迁移到另一个吗？ 由于两者都是 PostgreSQL 兼容的（Directus 支持额外的数据库），迁移是可行但不是微不足道的。如果你在带有 PostgreSQL 的 Directus 上，并想添加 Supabase，你可以将 Supabase 指向你现有的数据库或迁移数据。Directus 系统表和 Supabase 的身份验证模式需要共存或分离。反过来——在 Supabase 数据库顶部添加 Directus——实际上是一个文档良好的模式。Directus 可以内省现有表并创建其管理层，而不修改你的数据模式。