Directus vs Payload vs Supabase：2026 年該選擇哪個 CMS 後端
我在過去兩年推出了這三種工具的生產項目。每次我開始一個新項目時，在我們的架構討論中都會出現同樣的問題：Directus、Payload 還是 Supabase？答案從來不會是兩次相同的，因為它取決於市場行銷頁面不會告訴你的東西 -- 你的內容團隊實際上是如何運作的、你的數據關係是什麼樣的，以及你在 18 個月後會在哪裡。
這不是一份功能檢查清單比較。這是我在 Social Animal 進行項目範圍確定時實際使用的決策框架，已經通過數十個無頭構建進行了完善。到最後，你將知道哪個工具適合你的特定情況，而不會對自己產生懷疑。
目錄
- 每個工具的核心身份
- 架構和數據建模比較
- 內容編輯體驗
- 開發者體驗和 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 原生，非常好 | ❌ 僅表格編輯器 |
| 富文本編輯器 | ✅ WYSIWYG + 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 數據庫 |
| Starter/Pro | $99/月（Professional） | $35/月（Standard） | $25/月（Pro） |
| Team/Business | $399/月（Enterprise） | 自定義定價 | $599/月（Team） |
| 自主託管成本 | 免費（開源） | 免費（開源） | 免費（開源） |
| 包含數據庫 | ✅ 託管 | ✅ 託管 Postgres | ✅ 託管 Postgres |
| CDN/存儲 | 包含 | 包含 | 包含受限 |
定價截至 2026 年 Q1。查看每個平台的定價頁面獲取當前費率。
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 | 不適用（始終運行） |
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 上。如果預算緊張，你需要幫助做出正確的選擇，聯繫我們 -- 我們已經幫助很多團隊找到最經濟高效的架構。