我过去两年使用这三种工具发布了生产项目。每次启动新项目时，同样的问题都会在我们的架构讨论中出现：Directus、Payload 还是 Supabase？答案从不相同，因为这取决于营销页面不会告诉你的事情——你的内容团队实际如何运作、数据关系是什么样的，以及你在 18 个月后会在哪里。

这不是一份功能清单对比。这是我在 Social Animal 进行项目范围界定时实际使用的决策框架，通过数十个无头构建进行了优化。到最后，你将知道哪种工具适合你的具体情况，而不会对自己产生疑虑。

目录

Directus vs Payload vs Supabase: Which CMS Backend to Use in 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 繁重的团队来说，它的开发者体验最好。缺点？非开发人员无法在不更改代码的情况下修改数据模型。

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
);

-- Row Level Security
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 原生、非常好 ❌ 仅表编辑器
富文本编辑器 ✅ WYSIWYG + Markdown ✅ 基于 Lexical（优秀） ❌ 无
媒体库 ✅ 功能齐全 ✅ 功能齐全 ⚠️ 存储桶（无库 UI）
内容预览 ✅ 通过自定义模块 ✅ 原生实时预览 ❌ 自己构建
本地化 ✅ 内置翻译系统 ✅ 字段级本地化 ❌ 手动实现
内容版本控制 ✅ 内置修订 ✅ 草稿 + 版本 ❌ 自己构建
工作流 / 发布 ✅ Flows 系统 ✅ 草稿/发布状态 ❌ 需要自定义逻辑
非开发者友好 ✅ 非常 ✅ 是的 ❌ 根本不是

如果你的项目涉及内容编辑——那些撰写博文、管理产品目录、更新登陆页面的人——Supabase 是错误的工具。句号。你会花费数周时间来构建 Directus 和 Payload 在第一天给你的东西。

Payload 的编辑体验自 3.0 以来变得非常好。基于 Lexical 的富文本编辑器非常灵活，实时预览功能与 Next.js 前端配合得很好，管理面板感觉是原生的，因为它实际上在你的 Next.js 应用中运行。

Directus 拥有这三个中最成熟的管理面板。多年来一直在完善，自定义显示/界面系统意味着你可以构建复杂的编辑工作流而无需触及前端代码。对于内容繁重的组织，这非常重要。

Directus vs Payload vs Supabase: Which CMS Backend to Use in 2026 - architecture

开发者体验和 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 项目是一个巨大的优势。

// Next.js 服务器组件中的 Payload 本地 API
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 年第一季度的定价。查看每个平台的定价页面了解最新费率。

Payload Cloud 是小型到中型项目最实惠的托管选项。Supabase 的免费层对于原型制作和副项目是最慷慨的。Directus Cloud 针对愿意为精美托管体验付费的大型组织。

自托管大幅改变了等式。所有三个都在 $5-20/月的 VPS 上运行良好。Directus 和 Supabase 都有可靠的官方 Docker Compose 设置。Payload 可在 Next.js 运行的任何地方部署——Vercel、Railway、Fly.io、你自己的服务器。

对于我们的无头 CMS 开发项目，我们通常建议在 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 N/A（始终运行）

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 与 Astro 搭配得很好，适合内容繁重的网站，其中构建时渲染和岛屿架构比完整 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 都是开源的并可自托管的。如果数据所有权、成本控制和部署灵活性对你很重要，开源选项胜出。我们在我们的 无头 CMS 开发页面上更详细地涵盖了这一点。

哪个有最好的插件/扩展生态系统？ Directus 有一个社区扩展市场，用于自定义界面、显示和模块。Payload 有一个不断增长的插件生态系统，包括 SEO、表单、嵌套文档和重定向的官方插件。Supabase 有 Postgres 扩展（数百个），用途不同但功能强大。对于特定的 CMS 插件，Directus 目前拥有最多的选项。

对于一个小团队和有限的预算，最好的选择是什么？ Payload 自托管在 Vercel 的免费层或 Railway 的爱好计划上。你获得一个完整的 CMS，对于低流量项目完全免费。Supabase 的免费层对于原型制作也很优秀。Directus 需要自托管以供免费使用（无免费云层），但在 $5/月 VPS 上运行良好。如果预算紧张且需要帮助做出正确的选择，联系我们——我们已经帮助许多团队找到最具成本效益的架构。