你的部署完成了，網站上線了，三週後你的內容團隊給你發來信息：圖片上傳超時、嵌套類別無法保存、API回應時間攀升至800ms以上。在過去兩年裡，我在生產項目中用Directus、Payload和Supabase重現過這個場景——相同的症狀，每次根本原因都不同。答案取決於登陸頁面跳過的那些事情：你的編輯如何組織工作流程、你的關係圖實際上是什麼樣的，以及當A輪融資結束時你是否還在使用這個技術棧。下面是決定哪個後端能在你接下來六個衝刺週期內存活下來的框架。

這不是一個功能清單對比。這是我在Social Animal進行項目範圍界定時實際使用的決策框架，經過數十個無頭CMS構建的精煉。到本文結束時，你會知道哪個工具適合你的特定情況，而不會有任何疑慮。

目錄

Directus vs Payload vs Supabase：2026年使用哪個CMS後端 - 架構

每個工具的核心身份

在深入具體細節之前，你需要理解每個工具在核心上實際上是什麼，因為功能集的重疊可能會造成誤導。

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在第一天就給你的東西。

自Payload 3.0以來，Payload的編輯體驗已經變得非常好。基於Lexical的富文本編輯器很靈活，實時預覽功能與Next.js前端完美配合，管理面板感覺原生，因為它實際上在你的Next.js應用內運行。

Directus有三者中最成熟的管理面板。它經過多年的精煉，自定義顯示/界面系統意味著你可以構建複雜的編輯工作流程而不用接觸前端代碼。對於內容豐富的組織，這很重要。

Directus vs Payload vs Supabase：2026年使用哪個CMS後端 - 架構

開發者體驗和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年第一季度。查看各個平台的定價頁面瞭解當前費率。

Payload Cloud是小到中型項目最經濟的託管選項。Supabase的免費層是原型設計和副項目最慷慨的。Directus Cloud針對願意為精美託管體驗付費的大型組織。

自託管改變了等式。所有三個在$5-20/月VPS上運行良好。Directus和Supabase有官方Docker Compose設置，工作可靠。Payload在任何Next.js運行的地方部署——Vercel、Railway、Fly.io、你自己的服務器。

對於我們的無頭CMS開發項目，我們通常建議在Railway或Fly.io上自託管以降低成本效率，僅當客戶需要保證SLA時才使用託管雲。

性能和可擴展性基準

我在等效硬件（4vCPU、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（Web、移動、自助終端）
  • 你的前端不是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人公司的內部維基/知識庫。富文本內容、分類、搜索和基於角色的訪問。內容編輯的技術水平從技術性到非技術性。

任一CMS都運行良好。Directus對非技術團隊略有優勢，因為管理面板不需要代碼定制。如果你想要一個精美、品牌化的前端體驗，Payload更好。

遷移路徑和鎖定考慮

鎖定是真實的。在你承諾之前要考慮它。

Directus的鎖定最少，因為你的數據庫架構獨立於CMS。移除Directus，你仍然有一個乾淨、標準的SQL數據庫。你的數據不會被困在專有格式中。

Payload在標準Postgres（或MongoDB）表中存儲數據，但架構遵循Payload的約定。遷移離開意味著重構某些東西，但你的數據仍然在標準數據庫中。

Supabase就是Postgres。零鎖定。你可以獲取你的數據庫轉儲並在任何Postgres實例上運行它。如果Supabase明天消失，你需要替換一些API調用，但你的數據和架構將完全無損。

與Contentful或Sanity等專有CMS平台相比，所有三個的鎖定評分都很好，在這些平台中，你的數據存在於別人的雲中，導出它總是部分過程。

常見問題

我可以將Supabase用作無頭CMS嗎？ 技術上是的，但你要從頭開始構建CMS功能——內容編輯UI、媒體管理、修訂歷史、發佈工作流。對於只有開發人員內容管理的小項目，它可以工作。對於涉及非技術編輯的任何事情，使用真實的CMS，如Payload或Directus，如果需要，連接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上很好。如果預算緊張並且你需要幫助做出正確的選擇，聯繫我們——我們幫助很多團隊找到最具成本效益的架構。