Payload CMS vs Hygraph 2026：哪個無頭 CMS 適合你的技術棧？

客戶批准了線框圖。你的 Next.js 儲存庫已搭建完畢。然後你卡在 CMS 決策上，一切都陷入了停滯。Payload CMS 提供自託管、程式碼優先的控制——你擁有資料庫、編寫自訂掛鉤、在任何地方部署。Hygraph 為你提供受管理的 GraphQL API，處理擴展，無論你使用 100 次請求還是 100,000 次請求，都會按月計費。在過去兩年內，我曾用兩者都完成了生產專案。都沒有普遍意義上的勝者，但其中一個幾乎肯定會比另一個更符合你的技術棧、你的團隊 DevOps 容忍度和你的客戶預算。問題不是哪個 CMS 客觀上更優越——而是當晚上 11 點某些東西出故障時，或你的內容團隊要求 Hygraph 不公開的功能時，你願意承擔哪些權衡。以下是如何在不重建內容模型兩次的情況下做出決策的方法。

目錄

• 架構和哲學
• 開發者體驗
• 內容建模
• API 設計和查詢
• 效能和可擴展性
• 2026 年定價細目
• 自託管 vs SaaS：真實的權衡
• 驗證和存取控制
• 外掛生態系統和可擴展性
• 何時選擇哪個
• 常見問題

架構和哲學

這兩個 CMS 來自根本不同的世界觀，理解這一點比任何功能比較表更重要。

Payload CMS：程式碼優先、自託管

Payload 是一個 TypeScript 優先的開源無頭 CMS，運行在你自己的基礎設施上。自從 Payload 3.0 版本發佈（於 2024 年底登陸，並在最近的版本中得到改進），它直接構建在 Next.js 之上。這不是打字錯誤——Payload 字面上就是 Next.js 應用程式。你的 CMS 管理面板、你的 API 路由和你的前端都可以在同一個專案中。

配置就是程式碼。你在 TypeScript 文件中定義集合、字段、掛鉤和存取控制。沒有用於模式構建的 UI——你編寫它、提交它、版本控制它。根據你的團隊，這要麼非常好，要麼非常糟。

Payload 支援 MongoDB 和 PostgreSQL（透過 Drizzle ORM）作為資料庫適配器。截至 2026 年初，Postgres 適配器已經相當成熟，我會推薦大多數新專案使用。

Hygraph：GraphQL 原生 SaaS

Hygraph 採用相反的方法。它是一個完全受管理的平台，具有視覺模式構建器、託管 GraphQL API，並且零基礎設施管理。你在他們的 UI 中建模內容、配置 webhook、設置環境，然後就開始了。

在底層，Hygraph 運行在全球分佈式邊界基礎設施上。他們的內容 API 是純 GraphQL（沒有 REST 端點），這是一個有意的設計決策。他們已經深入投入 GraphQL 生態系統——包括對內容聯合、遠端來源和聯合類型的支持。

Hygraph 不是開源的。你正在租用該平台。

開發者體驗

本地開發

使用 Payload，本地開發就是 pnpm dev。你可以在配置更改時獲得熱重載，管理 UI 在 localhost 上運行，你可以在一個流程中調試所有內容。由於它是 Next.js，你的整個技術棧——前端、CMS、API——都在單一 next dev 命令中運行。這真的很好。在開發期間沒有遠端 API 延遲，沒有模擬層，沒有要管理的單獨 CMS 實例。

Hygraph 要求你在開發期間針對他們的雲 API 工作。他們確實提供開發環境和分支（在更高層級的計劃上），但你總是在發出網路請求。對於位於遠離其邊界節點的區域的團隊，這可能在開發期間增加明顯的延遲。好的一面是，設置零——註冊、創建專案、開始查詢。

TypeScript 支援

Payload 自動從你的配置生成類型。由於你的模式就是 TypeScript，類型始終是同步的。這是那種聽起來微不足道的東西，直到你處理了一個類型與現實漂移的 CMS。

Hygraph 需要你從他們的 GraphQL 模式生成類型，通常透過 GraphQL Code Generator。它可以工作，但這是你的管道中的額外步驟。如果有人在 Hygraph UI 中更改模式而沒有更新生成的類型，你會在執行時發現。

管理 UI

Payload 的管理面板是基於 React 的，完全可自訂。你可以交換字段元件、添加自訂視圖、注入你自己的路由。從 Payload 3.x 開始，它看起來乾淨而現代，儘管它不會贏得任何設計獎項。它是功能性的。

Hygraph 的管理 UI 是拋光的，為內容編輯器量身定制。內容編輯體驗對於非技術用戶來說可能更順暢。側邊欄導覽、資產管理和內容階段工作流程從純 UX 角度看起來更成熟。

功能	Payload CMS	Hygraph
本地開發	完整本地堆棧	僅雲 API
TypeScript	原生、自動生成	透過 GraphQL codegen
管理自訂	完整 React 元件覆蓋	受限（自訂側邊欄應用程式）
內容編輯器 UX	優良，開發者導向	拋光，編輯器導向
設置時間	5-15 分鐘（需要 Node + DB）	2 分鐘（註冊並開始）

內容建模

Payload 的方法

Payload 中的內容建模發生在程式碼中。這是一個簡化的例子：

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: 'users',
    },
    {
      name: 'publishedAt',
      type: 'date',
    },
  ],
}

這被版本控制、在 PR 中審查，並與你的應用程式碼一起部署。需要添加字段？更改配置，如果你在 Postgres 上運行遷移，然後部署。心智模型非常接近你如何使用 ORM 定義資料庫模式。

Payload 支援區塊、陣列、組、選項卡、條件邏輯和自訂字段類型。blocks 字段類型對於構建靈活的頁面構建器特別強大。

Hygraph 的方法

Hygraph 為你提供一個視覺模式編輯器。你拖放字段類型、配置驗證、在模型之間設置引用。這直觀且快速以進行初始設置。非開發人員可以理解模式（儘管他們是否應該更改它是一個不同的對話）。

Hygraph 支援元件（可重用字段組）、用於多型引用的聯合類型，以及一個稱為「Remote Sources」的概念，該概念允許你將外部 API 的資料直接聯合到你的內容圖中。該最後一個功能對於可組合架構確實是獨特和有用的。

缺點？Hygraph 中的模式更改發生在他們的 UI 中。儘管他們在企業計劃上提供環境分支和模式遷移，但你不會獲得 Payload 原生提供的相同程式碼審查工作流。

API 設計和查詢

Payload：REST + GraphQL

Payload 開箱即用地為你提供 REST API 和 GraphQL API。REST API 是從你的集合自動生成的，遵循可預測的慣例。GraphQL API 也是自動生成的。

但這是大多數人錯過的事情：Payload 還公開了一個本地 API，允許你從伺服器端程式碼直接查詢你的資料庫，無需任何 HTTP 開銷：

// 伺服器元件或 API 路由
const articles = await payload.find({
  collection: 'articles',
  where: {
    publishedAt: { less_than: new Date().toISOString() },
  },
  depth: 2,
  limit: 10,
})

這個本地 API 極其快速，因為它完全跳過了網路層。當你用 Payload 和 Next.js 在同一個專案中構建時，這是你獲取內容的主要方式。這是一個巨大的優勢。

Hygraph：純 GraphQL

Hygraph 是 GraphQL 一直。沒有 REST API。你的查詢看起來像這樣：

query GetArticles {
  articles(where: { publishedAt_lt: "2026-01-01" }, first: 10) {
    title
    content {
      html
    }
    author {
      name
    }
  }
}

GraphQL API 設計精良，具有堅實的過濾、分頁和排序。他們支援內容階段（DRAFT、PUBLISHED）、字段級本地化，以及一個從邊界提供快取內容的高效能讀取端點。

如果你的團隊已經大量使用 GraphQL——比如你正在使用 Apollo Client 或 urql——Hygraph 感覺很自然。如果你的團隊不了解 GraphQL，學習曲線是真實的。

效能和可擴展性

Payload 的效能完全取決於你的基礎設施。運行在一個體面的 VPS 上，具有 PostgreSQL 和適當的索引，我看到本地 API 的 P95 回應時間在 30 毫秒以下，REST/GraphQL 端點約 50-80 毫秒。但你負責擴展。需要處理流量峰值？這是你的——添加更多容器、擴展你的資料庫、設置快取。

Hygraph 為你處理擴展。他們邊界快取的讀取 API（他們稱之為「Content API」）從全球分佈式 CDN 節點提供回應。典型回應時間是全球 20-50 毫秒。對於讀取密集的內容網站，這很難在沒有自託管一側大量基礎設施工作的情況下達到。

對於我們無頭 CMS 開發專案，我們發現 Payload 與適當的快取（Next.js 中的 ISR 或按需重新驗證）的效能對於大多數真實世界的流量模式與 Hygraph 的邊界 API 相當。

2026 年定價細目

這就是事情變得有趣的地方。讓我列出真實的數字。

計劃	Payload CMS	Hygraph
免費/開源	$0（自託管，所有功能）	免費層：2 個座位、100 萬 API 呼叫/月、500 個內容條目
小團隊	~$20-50/月託管成本	Starter：$0（受限），Growth：自訂定價
中等規模	~$100-300/月（VPS + DB + 儲存）	Professional：起價 ~$399/月
企業	$500-2000/月基礎設施（變化很大）	Enterprise：自訂定價（~$1500+/月）
Payload Cloud	每個專案從 $30/月	N/A

Payload CMS 本身是 MIT 授權的，完全免費。你支付你自己的託管基礎設施。Hetzner VPS（$20/月）、受管 Postgres 實例（$15-30/月）和 S3 相容儲存（$5-10/月）在 $60/月以下為你提供生產就緒的設置。Payload 還提供 Payload Cloud——他們的受管託管服務——每個專案從 $30/月開始，如果你不想管理你自己的基礎設施，這可以簡化部署。

Hygraph 的免費層可用於小專案和原型。但一旦你需要超過 2 個團隊座位、自訂角色、多個環境或更高的 API 限制，你就會跳到他們的付費計劃。Professional 層在 2026 年運行大約 $399/月，這是一個有意義的經常性成本。企業定價是協商的，但通常以每月約 $1,500 開始。

這裡的細微之處是：如果你計入管理基礎設施的開發者時間，Hygraph 的定價對於沒有 DevOps 專業知識的小團隊可能實際上更便宜。反過來說，對於管理許多專案的機構，Payload 的免費核心意味著你的每個專案邊際成本只是託管。

自託管 vs SaaS：真實的權衡

這是核心緊張局勢，我想對兩方都誠實。

為什麼自託管（Payload）獲勝

• 資料所有權。 你的資料存放在你的資料庫中。句號。沒有供應商可以更改他們的條款、淘汰功能或扣留你的內容。
• 沒有 API 速率限制。 你受到你的基礎設施限制，而不是任意計劃層級的限制。
• 規模化成本。 一旦你超過特定流量閾值，自託管在成本上要便宜得多。
• 深度自訂。 掛鉤、自訂端點、自訂字段類型、管理 UI 覆蓋——沒有什麼你不能更改。
• 與你的應用程式共置。 在同一流程中運行 Payload 和 Next.js 可消除內容查詢的網路延遲。

為什麼 SaaS（Hygraph）獲勝

• 零操作負擔。 沒有要修補的伺服器、沒有要備份的資料庫、沒有要擔心的擴展。
• 全球邊界效能開箱即用。Hygraph 的 CDN 支持 API 在不你配置任何內容的情況下到處都很快。
• 內容聯合。 Hygraph 的 Remote Sources 功能允許你將來自外部 API 的資料直接聯合到你的內容圖中。這對於可組合架構確實很強大。
• 非開發人員友好。 當模式構建器是視覺的時，引入內容編輯器更簡單。
• 正常時間保證。 Hygraph 在其企業計劃上提供 SLA。自託管正常時間是你的問題。

對於基礎設施管理是優勢的團隊（或與Next.js 開發機構合作處理它的團隊），Payload 是更強的選擇。對於想要純粹專注於內容和前端開發的團隊，Hygraph 消除了真實的摩擦。

驗證和存取控制

Payload

Payload 具有內置驗證。用戶、會話、電子郵件驗證、密碼重置——都在那裡。你可以使用函數定義字段級和集合級存取控制：

access: {
  read: ({ req: { user } }) => {
    if (user?.role === 'admin') return true
    return {
      publishedAt: { less_than: new Date().toISOString() },
    }
  },
  update: ({ req: { user } }) => user?.role === 'admin',
}

這是真實的、程式碼級的存取控制。你可以寫任何邏輯。需要檢查外部服務？繼續。需要根據當前文件的字段限制存取？完成。

Hygraph

Hygraph 使用具有可配置權限的永久驗證令牌系統。你建立具有特定內容階段存取的令牌（例如，僅讀取 PUBLISHED、讀取 DRAFT、寫入）。為了更精細的控制，他們支援綁定到角色的自訂權限。

它有效，但不如 Payload 的方法靈活。你通過他們的 UI 配置權限，而不是在程式碼中表達。複雜場景——比如「編輯者只能更新其分配的類別中的文章」——在 Hygraph 中需要創意解決方法，但在 Payload 中微不足道。

外掛生態系統和可擴展性

Payload 的外掛生態系統自 3.0 以來已大幅增長。值得注意的外掛包括：

• @payloadcms/plugin-seo — SEO 中繼資料字段和預覽
• @payloadcms/plugin-form-builder — 動態表單建立
• @payloadcms/plugin-search — 全文搜尋整合
• @payloadcms/plugin-redirects — 重新導向管理
• 社區外掛用於 Stripe 整合、AI 內容生成等

編寫自訂外掛很簡單，因為它們只是修改 Payload 配置的函數。

Hygraph 的可擴展性來自：

• 應用程式和側邊欄擴展 — 編輯器中的自訂 UI 元素
• Webhook — 在內容更改時觸發外部工作流
• Remote Sources — 聯合外部 GraphQL 和 REST API
• Management API — 以程式設計方式管理模式和內容

Hygraph 的應用程式市場已經增長，但仍然小於 Payload 的外掛生態系統。Remote Sources 功能雖然是 Payload 沒有等效項的東西。能夠在沒有中間件的情況下將 Shopify 產品目錄直接縫入到你的內容圖中確實很有用。

何時選擇哪個

在使用兩者完成多個生產專案後，這是我誠實的建議框架：

選擇 Payload CMS 如果：

• 你是開發團隊（或與一個合作）熟悉 TypeScript 和基礎設施
• 你需要對 CMS 行為進行深度自訂
• 資料所有權和供應商獨立性對你很重要
• 你正在構建 Next.js 應用程式並想要本地 API 效能優勢
• 你是一個管理許多專案的機構，想要最小化每個專案的授權成本
• 你需要複雜的、程式碼驅動的存取控制

選擇 Hygraph 如果：

• 你想要零基礎設施管理
• 你的團隊已經投資於 GraphQL
• 你需要從多個來源進行內容聯合
• 你的內容編輯者需要開箱即用的拋光、視覺編輯體驗
• 你需要保證全球邊界效能，而無需配置 CDN
• 你的專案時間線很緊張，你不能承擔設置時間

對於我們在 Social Animal 構建的許多專案——特別是 Astro 和 Next.js 專案——Payload 已成為我們的預設建議。共置故事、TypeScript 原生方法和零授權成本符合我們的工作方式。但我們也完成了由需要受管理平台簡單性的團隊的客戶支持的 Hygraph 驅動專案。

選擇其中任何一個都沒有羞恥。羞恥在於在理解權衡之前選擇一個。如果你不確定哪個方向適合你的專案，我們很樂意談論它。

常見問題

Payload CMS 真的免費嗎？ Payload CMS 是 MIT 授權的，核心完全免費，包括所有功能——沒有「高級層」在付費牆後面鎖定功能。你為你自己的託管基礎設施支付（伺服器、資料庫、儲存）。Payload 還提供 Payload Cloud，他們的受管託管服務，如果你不想管理你自己的基礎設施，每個專案從 $30/月開始。

Hygraph 可以在沒有 GraphQL 知識的情況下工作嗎？ 內容編輯方面不需要任何 GraphQL 知識——編輯者只需使用視覺介面。然而，從 Hygraph 查詢內容的開發者必須使用 GraphQL。沒有 REST API 替代品。如果你的前端團隊對 GraphQL 不舒服，有一個學習曲線，你需要考慮到你的時間線。

Payload CMS 如何處理媒體和檔案上傳？ Payload 有一個內置的上傳系統，支援本地檔案儲存、S3 相容儲存（AWS S3、Cloudflare R2、MinIO）和其他適配器。它包括自動影像調整大小、焦點選擇，並根據你的配置生成回應式影像大小。對於大多數專案，將其連接到 S3 儲存桶或 Cloudflare R2 是推薦的方法。

Hygraph 支援本地化嗎？ 是的。Hygraph 具有字段級本地化的內置功能，這意味著你可以將單個字段標記為可本地化，而不是複製整個內容條目。這是一個強大的功能——你在專案設置中配置你的地區，然後內容編輯者可以在編輯者中的語言之間切換。Payload 也支援具有相似字段級方法的本地化。

我可以從 Hygraph 遷移到 Payload（或反之）嗎？ 遷移在任何一個方向都是可能的，但並不簡單。兩個系統都有允許你匯出和匯入內容的 API。主要挑戰是內容建模差異——尤其是豐富的文本，它在每個系統中的儲存方式不同。計劃遷移指令碼和徹底測試。對於大型內容庫，預算至少 2-4 週進行清潔遷移。

哪個 CMS 對電子商務最好？ 都不是電子商務平台，但兩者都與無頭商務解決方案整合良好。Hygraph 在這裡具有優勢，具有其 Remote Sources 功能，該功能可以將產品資料從 Shopify 或 commercetools 直接聯合到你的內容圖中。Payload 也適用於電子商務後端，但你通常會使用掛鉤和自訂端點自己構建整合。對於認真的電子商務專案，考慮任何一個 CMS 以及一個專用商務後端。

Payload 3.x 與 Payload 2.x 相比如何？ Payload 3.x 是一個主要的重寫。最大的變化是 Payload 現在作為 Next.js 外掛運行，而不是 Express 應用程式。這意味著你的 CMS 和前端共享同一流程，啟用本地 API 以進行零延遲查詢。它還添加了 PostgreSQL 支援（透過 Drizzle ORM）、即時預覽和重新設計的管理 UI。如果你使用過 Payload 2.x 並發現它有限制，3.x 值得再看一遍——它是一個根本不同的體驗。

2026 年 Payload CMS 的最佳託管設置是什麼？ 對於大多數專案，我們推薦：VPS 或容器服務（Railway、Render、Fly.io 或 Hetzner VPS with Docker）、受管 PostgreSQL（Neon、Supabase 或你的 VPS 提供者的服務），以及 Cloudflare R2 用於媒體儲存。小至中等專案的總成本通常運行 $40-80/月。對於更大的部署，帶有 Payload Cloud 的 Vercel 或 Kubernetes 設置效果很好。檢查我們的定價頁面以了解我們如何為客戶專案處理基礎設施設置。