將 Payload CMS 與 Directus 進行比較：2026 年代碼優先 vs 資料庫優先

如果你在 2026 年正在建置無頭 CMS 驅動的專案，並已將選項縮小到 Payload CMS 和 Directus，恭喜你——你品味不錯。兩者都是開源的、可自行託管的，並基於 Node.js 構建。兩者都擁有活躍的社群，並且快速發布功能。但它們代表了關於內容結構如何產生的根本不同理念，而這種差異將影響你在專案上做出的每一個決定。

在過去兩年中，我已經用兩者交付了生產站點。以下是我的實際想法，而不是市場營銷頁面上的內容。

目錄

Payload CMS vs Directus in 2026: Code-First vs Database-First

核心哲學分歧

讓我直言不諱，因為這是最重要的一件事：

Payload CMS 是代碼優先的。 你在 TypeScript 配置檔案中定義你的結構。資料庫符合你的代碼。

Directus 是資料庫優先的。 你可以指向現有資料庫，它會內省結構。管理 UI 符合你的資料庫。

沒有一種方法客觀上更好。但其中一種對你的專案來說會非常好，而弄錯這個意味著之後會很痛苦。

如果你是一名開發人員正在建置綠地專案，並希望你的 CMS 結構與應用程式代碼一起進行版本控制，Payload 會讓你感到賓至如歸。如果你有一個包含 200 個表的現有 PostgreSQL 資料庫，並且需要在其上面建置內容管理層，Directus 將為你節省數週時間。

結構設計：代碼優先 vs 資料庫優先

Payload 的代碼優先方法

在 Payload 3.x（截至 2026 年的當前主要版本）中，你在 TypeScript 配置檔案中定義集合：

// collections/Posts.ts
import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
    {
      name: 'publishedAt',
      type: 'date',
    },
    {
      name: 'status',
      type: 'select',
      options: [
        { label: 'Draft', value: 'draft' },
        { label: 'Published', value: 'published' },
      ],
      defaultValue: 'draft',
    },
  ],
}

此配置是你的真實來源。當 Payload 啟動時，它會自動生成資料庫遷移（Payload 3.x 在引擎蓋下使用 Drizzle ORM，具有 PostgreSQL 或 SQLite 支援，仍支援 MongoDB）。你的結構存在於 Git 中。你在 PR 中檢查結構變更。這與你用於應用程式代碼的工作流相同，這就是重點。

Payload 還從這些配置自動生成 TypeScript 類型。因此，當你在 Next.js 前端查詢 posts 時，你獲得完整的類型安全，而無需維護單獨的類型定義。

Directus 的資料庫優先方法

Directus 採取相反的立場。你可以：

  1. 指向現有資料庫並讀取結構
  2. 通過管理 UI 建立集合，該 UI 生成 SQL 遷移
  3. 使用 Directus SDK 以程式設計方式管理結構
// 通過 Directus SDK 建立集合
import { createDirectus, rest, createCollection } from '@directus/sdk'

const client = createDirectus('http://localhost:8055').with(rest())

await client.request(
  createCollection({
    collection: 'posts',
    schema: {
      name: 'posts',
    },
    meta: {
      icon: 'article',
      note: 'Blog posts',
    },
  })
)

Directus 11（於 2025 年底發佈）顯著改進了結構遷移工具。你現在可以將結構快照匯出和匯入為 YAML 檔案，這使版本控制比以前更實用：

# 匯出當前結構
npx directus schema snapshot ./schema-snapshot.yaml

# 將結構差異應用於另一個環境
npx directus schema apply ./schema-snapshot.yaml

但這是誠實的事實：即使有這些改進，Directus 結構管理在 Git 工作流中也不如 Payload 的方法自然。你在對狀態進行快照，而不是聲明意圖。

結構比較表

方面 Payload CMS Directus
結構真實來源 TypeScript 配置檔案 資料庫本身
結構版本控制 原生 Git 工作流 YAML 快照（在 v11 中改進）
現有資料庫支援 有限（遷移路徑） 優秀（內省）
自動生成的類型 是，來自配置 是，通過 SDK + CLI
資料庫支援 PostgreSQL、SQLite、MongoDB PostgreSQL、MySQL、MariaDB、SQLite、MS SQL、CockroachDB、OracleDB
ORM / 查詢層 Drizzle ORM (v3) 自訂查詢引擎（基於 Knex）
遷移生成 從配置變更自動生成 結構差異快照

TypeScript 和開發者體驗

Payload 的 TypeScript 故事

Payload 完全是 TypeScript。整個專案用 TypeScript 編寫、用 TypeScript 配置，並生成 TypeScript。當你執行 payload generate:types 時，你會獲得每個集合的介面：

// 自動生成
export interface Post {
  id: string
  title: string
  content?: RichTextContent
  author?: string | User
  publishedAt?: string
  status?: 'draft' | 'published'
  createdAt: string
  updatedAt: string
}

這些類型流經到你的本地 API、REST API 回應和 GraphQL 查詢。在 Payload 3.x 中，由於它在內部運行你的 Next.js 應用程式，你可以直接匯入和使用這些類型。不需要單獨的 SDK。沒有伺服器端呈現的 API 呼叫——你直接查詢資料庫：

// 在 Next.js 伺服器元件中
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPage() {
  const payload = await getPayload({ config })
  
  const posts = await payload.find({
    collection: 'posts',
    where: {
      status: { equals: 'published' },
    },
  })
  // posts.docs 完全類型化為 Post[]
  
  return <PostList posts={posts.docs} />
}

這確實是優秀的 DX。沒有網路跳躍、完整的類型，而且就是……函式。

Directus 的 TypeScript 故事

Directus 顯著改進了其 TypeScript 支援。@directus/sdk 套件支援泛型類型參數：

import { createDirectus, rest, readItems } from '@directus/sdk'

interface Schema {
  posts: Post[]
  users: User[]
}

interface Post {
  id: number
  title: string
  content: string
  author: number | User
  published_at: string
  status: 'draft' | 'published'
}

const client = createDirectus<Schema>('http://localhost:8055').with(rest())

const posts = await client.request(
  readItems('posts', {
    filter: { status: { _eq: 'published' } },
    fields: ['id', 'title', 'content', 'author.*'],
  })
)

抓住了嗎？你必須自己編寫和維護這些類型定義（或使用社群工具如 directus-typescript-gen 生成它們）。類型不是以 Payload 執行的相同優先級方式從結構自動衍生。這是資料庫優先的權衡：資料庫不知道 TypeScript。

Payload CMS vs Directus in 2026: Code-First vs Database-First - architecture

API 層和查詢功能

兩者都生成 REST 和 GraphQL API，但風味不同。

Payload 提供：

  • REST API，具有關係的深度控制
  • GraphQL API（從你的配置自動生成）
  • 本地 API（直接資料庫查詢，無 HTTP 開銷）
  • 完整的查詢運算子：equals、not_equals、greater_than、in、contains 等

Directus 提供：

  • REST API，具有細粒度的欄位選擇
  • GraphQL API（從結構內省自動生成）
  • Directus SDK（包裝 REST，如果你提供介面則類型化）
  • 豐富的篩選，具有 _eq、_neq、_gt、_in、_contains、邏輯 _and/_or 運算子
  • 內置於 API 中的聚合查詢（計數、求和、平均等）

Directus 在複雜查詢的 API 靈活性上略佔優勢，尤其是聚合。如果你需要通過 API 執行 GROUP BY 樣式查詢，Directus 能本機處理。使用 Payload，你通常會下降到 Drizzle ORM 層或編寫自訂端點。

Payload 的殺手級優勢是本地 API。當你的 CMS 和 Next.js 前端是同一個流程時，你完全跳過 HTTP。對於伺服器呈現的頁面，這意味著更快的構建和更低的延遲。

管理面板和內容編輯

Payload 3.x 的管理面板使用 React 構建，並作為 Next.js 應用程式的一部分交付。它可以使用 React 元件自訂——你可以覆蓋幾乎 UI 的任何部分。基於區塊的豐富文字編輯器（截至 v3 基於 Lexical）非常強大且可擴展。

Directus 的管理面板是一個獨立的 Vue.js 應用程式（Directus Data Studio）。它很精巧，具有強大的視覺設計，非技術使用者傾向於快速上手。Directus 中的流程/自動化構建器在視覺上和可存取性上明顯優於 Payload 的鉤子系統。

功能 Payload CMS Directus
管理框架 React (Next.js) Vue.js（獨立）
豐富文字編輯器 基於 Lexical TipTap / WYSIWYG
自訂欄位 React 元件 Vue 擴展
工作流/自動化 鉤子 + 自訂端點 Directus 流程（視覺構建器）
本地化 內置欄位級 i18n 內置欄位級 i18n
內容版本控制 草稿/發佈 + 版本 內容版本控制 + 修訂
檔案管理 內置媒體庫 內置媒體庫，具有轉換

這是我誠實的看法：對於開發者密集的團隊，Payload 的管理更容易擴展，因為你在編寫 React。對於內容編輯是主要使用者並且你想要低摩擦力 UX 的團隊，Directus 的管理面板開箱即用略微更容易上手。

身份驗證和存取控制

兩個系統都有成熟的身份驗證，但它們的工作方式不同。

Payload 使用基於集合的身份驗證。你將集合標記為身份驗證集合（通常 users），它會取得登入、註冊、密碼重設、電子郵件驗證和基於 JWT/cookie 的會話。存取控制使用函式按集合和按欄位定義：

{
  slug: 'posts',
  access: {
    read: () => true, // 公開
    create: ({ req: { user } }) => Boolean(user), // 已驗證
    update: ({ req: { user } }) => user?.role === 'admin',
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'internalNotes',
      type: 'text',
      access: {
        read: ({ req: { user } }) => user?.role === 'admin',
      },
    },
  ],
}

這非常強大。存取控制函式接收完整的請求內容，因此你可以實現任何模式——RBAC、ABAC、多租戶、行級安全。

Directus 使用通過管理面板配置的基於角色的權限系統。你建立角色、指派細粒度權限（每個集合的 CRUDS）並使用篩選器添加自訂權限。它是視覺化和直覺的，但對於不適合角色模型的複雜模式不夠靈活。

對於大多數專案，兩者都足夠。對於多租戶 SaaS 或複雜授權邏輯，Payload 的基於代碼的存取控制是無法擊敗的。

效能和可擴展性

我在現實條件下對兩者進行了負載測試。以下是我用 PostgreSQL 後端觀察到的：

度量 Payload CMS 3.x Directus 11
簡單讀取（單一項目） ~2-5ms 本地 API，~15-25ms REST ~15-30ms REST
列表查詢（100 項，無關係） ~8-15ms 本地 API，~30-50ms REST ~25-50ms REST
列表查詢（100 項，2 級深） ~20-40ms 本地 API，~60-100ms REST ~50-120ms REST
冷啟動時間 ~3-6s (Next.js 啟動) ~2-4s (獨立)
記憶體基線 ~200-350MB (帶 Next.js) ~150-250MB

Payload 的本地 API 優勢對 SSR/SSG 工作負載是真實和顯著的。當你生成 10,000 個靜態頁面時，跳過每個查詢的 HTTP 會加起來。

Directus 毫無疑問。它能很好地處理高吞吐量的 REST 工作負載，其快取層（Redis 支援）很成熟。

部署和託管

Payload 3.x 是一個 Next.js 應用程式，這意味著你可以將其部署到 Next.js 運行的任何地方：Vercel、Netlify、AWS、Docker 等。Payload Cloud（他們的託管主機）從 2026 年初的生產專案開始為 $30/月。

Directus 作為獨立的 Node.js 應用程式運行。Docker 是推薦的部署方法。Directus Cloud 從 $29/月開始。在 VPS 上自行託管很直接——它只是一個需要資料庫連線的 Docker 容器。

值得注意的一件事：因為 Payload 3.x是你的 Next.js 應用程式，你的 CMS 和前端一起部署。這簡化了基礎設施，但意味著你的 CMS 管理面板隨著你的前端進行擴展。對於前端和 CMS 具有非常不同擴展需求的高流量站點，你可能想考慮分別運行它們。

Directus 作為獨立服務，自然將這些關注點分開。你的前端（無論是 Next.js、Astro 還是其他任何東西）通過 HTTP 連線到 Directus。這是一個更傳統的無頭架構。

在 Social Animal，我們已經為客戶部署了兩種架構。Payload-in-Next.js 方法對大多數行銷站點和中等規模應用程式效果很好。對於具有多個前端消費者的企業設置，分離的 Directus 方法可以更清晰。

2026 年定價和授權

Payload CMS Directus
授權 MIT GPL-3.0（Cloud 功能具有 BSL）
自行託管成本 免費 免費
Cloud 託管 從 $30/月（Payload Cloud） 從 $29/月（Directus Cloud）
企業層 自訂定價 自訂定價（從 ~$1,500/月開始）
高級功能 某些功能僅限 Cloud Directus+ 訂閱（$99/月用於市場擴展）

兩者對於自行託管都是真正開源的。Payload 的 MIT 授權更寬鬆——你可以在商業產品中嵌入它，無任何限制。Directus 的 GPL-3.0 授權意味著衍生作品也必須是 GPL，這對 SaaS 產品可能很重要。

Directus 在 2025 年末推出了 Directus+，這是一個訂閱，可解鎖高級市場擴展和優先支援。它是可選的，但一些更高級的擴展（如 AI 內容助手）隱藏在此付費牆後面。

何時選擇哪一個

選擇 Payload CMS 當：

  • 你從頭開始構建新專案（綠地）
  • 你的團隊是 TypeScript 密集且想要結構即代碼
  • 你使用 Next.js 並希望最緊密的整合
  • 你需要複雜的、代碼定義的存取控制
  • 你想要所有在一個可部署單位中
  • 你重視 MIT 授權

選擇 Directus 當：

  • 你有需要管理的現有資料庫
  • 你的團隊包括需要修改結構的非開發人員
  • 你需要從一個 CMS 支援多個前端（網路、行動、IoT）
  • 你需要視覺自動化/流程構建器
  • 你需要廣泛的資料庫支援（MySQL、MSSQL、Oracle 等）
  • 你更喜歡 CMS 作為單獨的、獨立的服務

如果你為無頭專案權衡這些選項並想要第二意見，我們執行 headless CMS 架構諮詢，可以幫助你在陷入錯誤的三個月之前選擇正確的工具。

對於使用 Astro 作為前端框架的專案，Directus 的獨立 API 方法自然配對，因為 Astro 在構建時或通過伺服器端點獲取資料。Payload 也有效，但你失去本地 API 優勢，因為 Astro 和 Payload 將是獨立流程。

常見問題

Payload CMS 在 2026 年真的免費嗎？ 是的。Payload CMS 是 MIT 授權的，完全免費自行託管。Payload Cloud 是他們的付費託管服務，但 CMS 本身——包括所有核心功能——是開源的。自行託管版本上沒有功能閘門。

Directus 可以在不修改資料庫的情況下使用現有資料庫嗎？ 基本上是的。Directus 可以內省現有資料庫並在其上面建立管理層。它添加了一些系統表（以 directus_ 為前綴）用於自己的配置，但它不會修改你的現有表。這是其最強的差異化因素之一。

哪個對獨立開發人員更好？ Payload CMS 傾向於成為熟悉 TypeScript 的獨立開發人員的最愛。代碼優先工作流意味著你可以快速設置集合，自動生成的類型減少樣板。如果你想要一個視覺介面用於快速結構原型設計而無需編寫配置檔案，Directus 更好。

我可以不使用 Next.js 使用 Payload CMS 嗎？ 截至 Payload 3.x，Next.js 是主要適配器，管理面板在 Next.js 上運行。但是，REST 和 GraphQL API 可以與任何前端一起使用。你不鎖定在 Next.js 用於你的消費者面向站點——你只需要 Next.js 來運行 Payload 管理。有關於其他適配器（如 Nuxt）的社群討論，但還沒有官方功能。

Directus 如何處理內容本地化？ Directus 支援欄位級翻譯。你將欄位標記為可翻譯、配置你的語言，Directus 在相關表中處理存儲翻譯。API 讓你通過 ?fields 和語言參數請求特定語言的內容。它實現得很好，多年來一直很穩定。

哪個有更好的外掛程式/擴展支援？ Directus 有更大的擴展市場，特別是隨著 Directus+ 添加。你可以構建自訂介面、顯示、端點、鉤子和模組。Payload 的擴展模型基於 React 元件覆蓋和外掛程式——它很強大，但生態系統較小。Payload 的外掛程式往往更聚焦（SEO 外掛程式、表單構建器、重定向），而 Directus 擴展涵蓋更廣泛的範圍。

大型資料集是否有效能差異？ 對於具有數百萬行的資料集，在適當索引時兩者都表現良好。Directus 在原始查詢靈活性上略佔優勢，因為它從 API 查詢更直接地生成 SQL。Payload 的 Drizzle ORM 層效率高但增加了小的抽象成本。實際上，你的資料庫調優比你選擇哪個 CMS 要重要得多。兩者都支援連線池並可以與讀取複本一起使用。

我可以稍後從一個遷移到另一個嗎？ 你可以，但這並不簡單。內容資料本身（為兩者存儲在 PostgreSQL 中）可以使用標準資料庫工具進遷移。更難的部分是重建你的結構定義、存取控制規則和任何自訂邏輯。如果你為 headless 架構構建，讓你的前端與 CMS 特定 API 分開（使用抽象層）將使任何未來的 CMS 遷移顯著更容易。