Directus vs Payload vs Supabase：2026年哪个后端适合你的技术栈
你的部署完成了，网站上线了，三周后你的内容团队给你发来消息：图片上传超时了，嵌套分类无法保存，API响应时间攀升到了800ms以上。在过去两年里，我在生产项目中使用Directus、Payload和Supabase重新构建过这个场景 — 症状相同，但每次根本原因都不一样。答案取决于登录页面省略的一些东西：你的编辑如何组织工作流程、你的关系图看起来是什么样的，以及当Series A融资完成时你是否仍在使用这个技术栈。这里是确定哪个后端能够在你的下一个六个冲刺周期中存活下来的决策框架。
这不是功能清单比较。这是我在Social Animal制定项目范围时实际使用的决策框架，通过数十个无头CMS构建进行了改进。在结束之前，你将知道哪个工具适合你的具体情况，而不会再有疑虑。
目录
- 每个工具的核心身份
- 架构和数据建模对比
- 内容编辑体验
- 开发者体验和API设计
- 身份验证、权限和行级安全
- 自托管、云和2026年定价
- 性能和可扩展性基准
- 决策框架：何时使用哪个
- 真实项目场景
- 迁移路径和锁定考虑
- 常见问题
每个工具的核心身份
在我们深入细节之前，你需要理解每个工具在其核心实际上是什么，因为功能集之间的重叠可能会造成误导。
Directus 是一个数据库优先的无头CMS。它用一个自动生成的API和一个精美的管理面板封装现有的SQL数据库（Postgres、MySQL、SQLite、MS SQL、MariaDB、CockroachDB）。你设计你的数据库，Directus内省它并给你一个UI。它用TypeScript编写，运行在Node.js上。
Payload 是一个代码优先的无头CMS，构建在Next.js之上（从Payload 3.0开始）。你在TypeScript配置文件中定义集合和字段，Payload从该配置生成数据库模式、管理UI、API端点和TypeScript类型。它使用MongoDB或Postgres作为其数据库层。
Supabase 是一个开源的Firebase替代品 — 一个构建在Postgres之上的后端即服务平台。它真的不是一个CMS。它是一个具有身份验证、存储、实时订阅和边缘函数的数据库平台。但团队一直在将其用作CMS后端，这就是为什么它一直出现在这些比较中。
这个区分比这篇文章中的任何其他东西都重要。Directus和Payload是为内容管理目的而构建的。Supabase是一个通用后端，只要花费足够的努力，你可以将其塑造成内容管理系统。
架构和数据建模对比
Directus：数据库优先
Directus不拥有你的模式。你可以将其指向现有数据库，它会自动生成管理面板。当你与传统系统一起工作或你的数据模型为内容管理之外的多个应用程序服务时，这是真正强大的。
Directus中的关系建模是可靠的。M2M、M2O、O2M，甚至翻译都通过UI进行处理。但有一个问题：因为Directus内省数据库而不是从代码生成它，你的模式更改发生在两个地方 — 迁移和Directus管理面板。如果你在团队环境中纪律不严格，这可能会变得混乱。
# Directus模式快照（简化）
collections:
- collection: articles
fields:
- field: title
type: string
interface: input
- field: content
type: text
interface: input-rich-text-md
- field: author
type: uuid
interface: select-dropdown-m2o
related_collection: authors
Payload：代码优先
Payload 3.0（2026年的当前版本）在Next.js内部作为插件运行。你的集合在TypeScript中定义：
import { CollectionConfig } from 'payload'
export const Articles: CollectionConfig = {
slug: 'articles',
admin: {
useAsTitle: 'title',
},
fields: [
{
name: 'title',
type: 'text',
required: true,
},
{
name: 'content',
type: 'richText',
},
{
name: 'author',
type: 'relationship',
relationTo: 'authors',
},
],
}
这种代码优先的方法意味着你的模式存在于版本控制中。你可以从你的配置中获得完整的TypeScript类型自动生成。对于TypeScript重的团队来说，这是三者中最好的DX。缺点是？非开发人员无法在不进行代码更改的情况下修改数据模型。
Supabase：SQL优先
使用Supabase，你在编写SQL。原始Postgres。你定义你的表，设置行级安全策略，然后通过自动生成的REST API（PostgREST）或JavaScript客户端进行交互。
CREATE TABLE articles (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
title TEXT NOT NULL,
content JSONB,
author_id UUID REFERENCES authors(id),
created_at TIMESTAMPTZ DEFAULT now(),
published BOOLEAN DEFAULT false
);
-- 行级安全
ALTER TABLE articles ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Public can read published articles"
ON articles FOR SELECT
USING (published = true);
你可以获得最大的灵活性，但开箱即用没有内容管理UI。你要么构建一个自定义管理面板，使用第三方工具，要么将Directus之类的东西连接到同一个Postgres实例上（是的，人们确实会这样做）。
内容编辑体验
CMS与非CMS的区别在这里最明显。
| 功能 | Directus | Payload | Supabase |
|---|---|---|---|
| 内置管理UI | ✅ 精美，可定制 | ✅ Next.js原生，非常好 | ❌ 仅表格编辑器 |
| 富文本编辑器 | ✅ 所见即所得 + Markdown | ✅ 基于Lexical（优秀） | ❌ 无 |
| 媒体库 | ✅ 全功能 | ✅ 全功能 | ⚠️ 存储桶（无库UI） |
| 内容预览 | ✅ 通过自定义模块 | ✅ 原生实时预览 | ❌ 自己构建 |
| 本地化 | ✅ 内置翻译系统 | ✅ 字段级本地化 | ❌ 手动实现 |
| 内容版本管理 | ✅ 修订版本内置 | ✅ 草稿 + 版本 | ❌ 自己构建 |
| 工作流 / 发布 | ✅ Flows系统 | ✅ 草稿/发布状态 | ❌ 需要自定义逻辑 |
| 非开发者友好 | ✅ 非常 | ✅ 是的 | ❌ 完全不是 |
如果你的项目涉及内容编辑 — 写博客文章的人、管理产品目录的人、更新登录页面的人 — Supabase是错误的工具。句号。你会花费数周时间构建Directus和Payload在第一天给你的东西。
自3.0以来，Payload的编辑体验得到了显著改善。基于Lexical的富文本编辑器非常灵活，实时预览功能与Next.js前端配合得很好，管理面板感觉是原生的，因为它实际上在你的Next.js应用内运行。
Directus有三者中最成熟的管理面板。它经过多年的改进，自定义显示/界面系统意味着你可以构建复杂的编辑工作流程而无需触及前端代码。对于内容丰富的组织来说，这很重要。
开发者体验和API设计
API样式
Directus开箱即用提供REST和GraphQL，加上JavaScript SDK。REST API遵循一致的模式，GraphQL实现是从你的模式自动生成的。它可以工作，但GraphQL对于复杂的嵌套查询可能感觉有限。
Payload生成REST和GraphQL API，加上你可以完全访问本地API（直接数据库查询，无HTTP开销）。由于Payload 3.0在你的Next.js应用内运行，你可以在你的服务器组件中直接调用payload.find()。这对Next.js项目是一个巨大的优势。
// Payload本地API在Next.js服务器组件中
import { getPayload } from 'payload'
import config from '@payload-config'
export default async function ArticlePage({ params }) {
const payload = await getPayload({ config })
const article = await payload.findByID({
collection: 'articles',
id: params.id,
depth: 2,
})
return <Article data={article} />
}
Supabase的API由PostgREST自动生成，JavaScript客户端库真的很优秀。查询构建器感觉很自然：
const { data, error } = await supabase
.from('articles')
.select('*, author:authors(*)')
.eq('published', true)
.order('created_at', { ascending: false })
.range(0, 9)
Supabase还有实时订阅，Directus和Payload都没有原生提供。如果你需要实时数据更新（聊天、通知、协作编辑），Supabase默认胜出。
类型安全
Payload有最好的TypeScript故事。类型从你的集合配置生成，从端到端的一切都是强类型的。Supabase有可靠的类型生成，通过他们的CLI（supabase gen types typescript），它从你的数据库模式创建类型。Directus有一个TypeScript SDK，但类型生成需要额外的设置，集成度不如那么紧密。
身份验证、权限和行级安全
Supabase真正闪耀的地方是这里。Postgres行级安全（RLS）是三者中最精细、最经过战斗考验的权限模型。你在数据库级别定义策略，无论如何访问数据，它们都适用。对于多租户SaaS应用程序来说，它是非常强大的。
Directus有一个基于角色的权限系统，在集合和字段级别工作。它在管理面板中很直观，足以满足大多数CMS使用情况。你可以设置每个角色的CRUD权限，甚至添加自定义过滤器规则。
Payload通过配置中的函数提供字段级和集合级访问控制：
{
slug: 'articles',
access: {
read: () => true,
create: ({ req: { user } }) => user?.role === 'editor',
update: ({ req: { user } }) => user?.role === 'editor',
delete: ({ req: { user } }) => user?.role === 'admin',
},
fields: [
{
name: 'internalNotes',
type: 'textarea',
access: {
read: ({ req: { user } }) => user?.role === 'admin',
},
},
],
}
对于具有编辑、审阅者和管理员的标准CMS，三者都很好用。对于具有动态权限规则的复杂多租户应用程序，Supabase的RLS是最强大的选项。
自托管、云和2026年定价
三者都是开源的并且可自托管的。但云定价告诉你很多关于他们目标市场的事情。
| 计划 | Directus Cloud | Payload Cloud | Supabase Cloud |
|---|---|---|---|
| 免费层 | ❌ 无免费云 | ✅ 1个项目，有限 | ✅ 2个项目，500MB数据库 |
| 启动/专业版 | $99/月（专业版） | $35/月（标准版） | $25/月（专业版） |
| 团队/业务版 | $399/月（企业版） | 自定义定价 | $599/月（团队版） |
| 自托管成本 | 免费（开源） | 免费（开源） | 免费（开源） |
| 包括数据库 | ✅ 托管 | ✅ 托管Postgres | ✅ 托管Postgres |
| CDN/存储 | 包括 | 包括 | 包括有限 |
截至2026年Q1的定价。检查每个平台的定价页面以获取当前费率。
Payload Cloud是小型到中型项目最实惠的托管选项。Supabase的免费层对原型设计和副业项目最慷慨。Directus Cloud针对愿意为精美托管体验付费的大型组织。
自托管改变了方程式。三者在$5-20/月的VPS上都运行得很好。Directus和Supabase有可靠的官方Docker Compose设置。Payload在Next.js运行的任何地方都可以部署 — Vercel、Railway、Fly.io、你自己的服务器。
对于我们的项目，我们通常建议在Railway或Fly.io上自托管以获得成本效益，只有当客户需要有保证的SLA时才使用托管云。
性能和可扩展性基准
我在等效硬件（4个vCPU、8GB RAM、Postgres 16）上用约50,000个内容记录的数据集进行了一些非正式基准测试。
| 操作 | Directus | Payload | Supabase |
|---|---|---|---|
| 简单列表查询（20项） | ~45ms | ~12ms（本地API）/ ~38ms（REST） | ~18ms |
| 嵌套关系查询（深度3） | ~120ms | ~35ms（本地API）/ ~95ms（REST） | ~55ms |
| 全文搜索（1000结果） | ~180ms | ~85ms | ~40ms（pg_trgm） |
| 批量插入（1000条记录） | ~2.1s | ~1.8s | ~0.9s |
| 冷启动时间 | ~3.5s | ~2.8s | 不适用（始终运行） |
Payload的本地API对Next.js应用程序来说是最快的选项，因为没有HTTP开销 — 你直接从你的渲染过程查询数据库。Supabase的原始Postgres性能对于数据繁重的操作来说很难被超越。Directus通过其抽象层添加了一些开销，但对于内容提供工作负载来说是完全可以接受的。
对于搜索特别来说，Supabase有显著的优势，因为你可以使用Postgres的原生全文搜索、三元组索引，甚至pgvector扩展进行语义搜索。Directus和Payload都支持搜索，但依赖于它们自己的实现，而不是利用Postgres直接。
决策框架：何时使用哪个
这是实际的框架。回答这些问题，你的选择就变得显而易见。
选择Directus当：
- 你的内容团队很大且不具技术性
- 你需要用CMS层封装现有数据库
- 你使用的数据库不是Postgres（MySQL、MS SQL等）
- 你需要一个为多个前端（网络、移动、信息亭）服务的独立CMS
- 你的前端不是Next.js（也许你使用Astro、Nuxt或SvelteKit）
- 你想要最大的灵活性来自定义管理UI而无需代码
Directus与内容丰富的网站配对时效果很好，其中构建时渲染和岛屿架构比完整的React框架更有意义。
选择Payload当：
- 你的前端是Next.js（这是关键用例）
- 你的团队是TypeScript优先的，希望到处都有类型安全
- 你想要CMS和前端在一个可部署单元中
- 你需要实时预览和可视化编辑功能
- 你想要在版本控制中定义的代码模式
- 你在构建一个网站，其中内容模型是预先定义好的
Payload是我们对Next.js开发项目的首选推荐，其中内容管理是核心要求。集成是无与伦比的。
选择Supabase当：
- 你在构建应用程序，而不是内容网站
- 你需要实时功能（聊天、实时更新、协作编辑）
- 你需要复杂的多租户权限（RLS是王者）
- 你的主要需求是后端，内容是次要的
- 你想要使用Postgres扩展（pgvector、PostGIS、pg_cron）
- 你的团队习惯于构建自己的管理界面
- 你在构建一个SaaS产品，其中用户生成的数据比编辑内容更重要
真实项目场景
场景1：具有博客的营销网站
最佳选择：Payload（如果是Next.js）或Directus（如果是Astro/其他）
一个具有50-200个页面、博客的营销网站，和一个由2-3个人组成的小内容团队。你需要登录页面灵活性、图像优化、SEO元数据管理，也许还有一些A/B测试。
Payload的实时预览功能在这里是完美的。内容编辑可以看到页面发布前的确切外观。基于块的字段类型让你构建灵活的登录页面，而不会给编辑足够的绳索去绞死自己。
场景2：电商产品目录
最佳选择：Directus或Payload
具有5,000多个SKU、复杂分类、多个价目表和库存系统集成的产品目录。这里的关键是数据建模灵活性和高效处理结构化数据的能力。
如果你需要在不迁移数据的情况下连接到现有产品数据库，Directus略占上风。如果你从头开始构建并希望在你的Next.js店面中获得类型安全的产品查询，Payload胜出。
场景3：多租户SaaS平台
最佳选择：Supabase
一个平台，每个客户都有自己的数据空间，具有基于角色的访问、实时通知和用户生成的内容。你需要行级安全、边缘函数以处理业务逻辑，以及水平扩展的能力。
这不是一个CMS项目 — 这是一个应用程序后端项目。Supabase正是为此而构建的。
场景4：内部知识库
最佳选择：Payload或Directus
一个200人公司的内部wiki/知识库。富文本内容、分类、搜索和基于角色的访问。内容编辑从技术性到非技术性各不相同。
任一CMS都可以在这里工作得很好。对于非技术型团队，Directus略占优势，因为管理面板无需零代码定制。如果你想要一个精美的、品牌化的前端体验，Payload更好。
迁移路径和锁定考虑
锁定是真实的。在你承诺之前要考虑到这一点。
Directus 的锁定最少，因为你的数据库模式独立于CMS。移除Directus，你仍然有一个干净的、标准的SQL数据库。你的数据没有被困在专有格式中。
Payload 在标准Postgres（或MongoDB）表中存储数据，但模式遵循Payload的约定。迁移出去意味着重新组织一些东西，但你的数据仍然在标准数据库中。
Supabase 就是Postgres。零锁定。你可以获取你的数据库转储并在任何Postgres实例上运行它。客户端库只是PostgREST和GoTrue的包装。如果Supabase明天消失，你需要替换一些API调用，但你的数据和模式会完全完整。
与Contentful或Sanity等专有CMS平台相比，三者在锁定方面的表现都很好，其中你的数据存在于别人的云中，导出它总是一个部分过程。
常见问题
我可以使用Supabase作为无头CMS吗？ 从技术上讲可以，但你将从头开始构建CMS功能 — 内容编辑UI、媒体管理、修订历史、发布工作流。对于只有开发者进行内容管理的小项目，它可以工作。对于涉及非技术编辑的任何项目，使用Payload或Directus之类的真正CMS，如果需要，可以连接Supabase以处理应用程序数据。
Payload真的免费吗？有什么隐患吗？ Payload CMS在MIT许可证下是真正的开源。你可以永远免费自托管。Payload Cloud是他们的付费托管服务，起价$35/月。除此之外，如果你想称之为一个问题，那就是Payload Cloud有一些高级功能，如表单构建器和SEO插件，这些是免费的，但受益于托管环境。核心CMS在不花费任何费用的情况下是完全功能的。
我可以同时使用Directus和Supabase吗？ 当然可以，而且这是我多次使用过的一种模式。将Directus指向Supabase Postgres数据库。你获得Directus的管理面板用于内容管理，以及Supabase的实时订阅、身份验证和边缘函数用于应用程序功能。这两个工具配合得很好，因为它们在不同的层运行。
对于Next.js项目哪个最好？ Payload，差距不近。从Payload 3.0开始，CMS在你的Next.js应用内作为插件运行。你在服务器组件中获得本地API用于零开销数据库查询、原生实时预览和单次部署。我们在Next.js开发工作中经常使用这个组合。
这些与2026年的Strapi相比如何？ Strapi v5是一个可靠的选项，但在几个方面有所落后。其管理面板与Payload的相比感觉过时，其TypeScript支持不如强，其许可模型变得更具限制性。Directus提供了类似的数据库封装方法，有一个更现代的UI。Payload为TypeScript团队提供了更好的DX。Strapi的主要优势是其更大的插件生态系统和更大的社区，但差距在缩小。
Sanity、Contentful或其他SaaS CMS平台怎么样？ Sanity和Contentful是很棒的产品，但它们是专有的SaaS平台。你的数据存在于他们的服务器上，定价随着使用量扩展（而且会变得非常昂贵），你依赖于他们的基础设施。Directus、Payload和Supabase都是开源且可自托管的。如果数据所有权、成本控制和部署灵活性对你很重要，开源选项会赢。
哪个有最好的插件/扩展生态系统？ Directus有一个市场，带有社区扩展用于自定义界面、显示和模块。Payload有一个不断增长的插件生态系统，带有官方插件用于SEO、表单、嵌套文档和重定向。Supabase有Postgres扩展（数百个），这有不同的用途，但非常强大。对于特定于CMS的插件，Directus目前有最多的选项。
对于预算有限的小团队，最好的选择是什么？ 在Vercel的免费层或Railway的业余计划上自托管Payload。你获得一个完整的CMS，零低流量项目的月度成本。Supabase的免费层也非常适合原型设计。Directus需要自托管以实现免费使用（无免费云层），但在$5/月的VPS上运行得很好。如果预算紧张，你需要帮助做出正确的选择，请与我们联系 — 我们已经帮助许多团队找到了最具成本效益的架构。