Directus 與 Supabase：2026 年選擇後端指南

過去三年，我在 Directus 和 Supabase 上都部署過專案。每當有人問我「我應該選擇哪一個？」，我的回答都是一樣的：取決於你實際上在構建什麼。這不是逃避問題 -- 這兩個工具確實服務於不同的主要目的，儘管它們以令人驚訝的方式重疊。Directus 是一個無頭 CMS，它為任何 SQL 資料庫包裝一個美觀的管理 UI 和 REST/GraphQL API。Supabase 是一個建立在 PostgreSQL 上的 Firebase 替代品，為你提供身份驗證、實時訂閱、儲存和邊緣函數。重疊之處？兩者都給你一個資料庫，兩者都給你一個 API，兩者都有一個用於管理資料的儀表板。但每個工具背後的理念是根本不同的，而這種理念塑造了你將來做出的每一個決定。

讓我帶你了解我用兩者在生產環境中構建所學到的東西。

目錄

Directus vs Supabase in 2026: Choosing Your Backend

Philosophy and Core Identity

Directus 稱自己為「資料平台」，但讓我們說實話 -- 它的核心是一個無頭 CMS。它接收你現有的 SQL 資料庫（PostgreSQL、MySQL、MariaDB、MS SQL、SQLite、Oracle、CockroachDB），並在其上面添加一個內容管理介面。關鍵見解：Directus 不擁有你的資料模式。你可以將它指向一個現有的資料庫，它會自動內省表和關係。如果你已經有一個資料庫並需要一個管理層，這很強大。

Supabase 是一個後端即服務（BaaS）。它是具有完整功能的 PostgreSQL：身份驗證、檔案存儲、實時訂閱、邊緣函數和用於 AI 工作負載的向量嵌入。Supabase 假設你在構建一個應用程式，而不是管理內容。儀表板是為開發人員設計的，而不是為內容編輯器設計的。

這種哲學上的差異比任何功能比較都更重要。如果你在構建一個以內容為驅動的網站，編輯者需要發布博客文章、管理媒體和預覽更改 -- Directus 是為此而專門設計的。如果你在構建一個 SaaS 應用程式，使用者註冊、存儲資料並實時互動 -- Supabase 是為此而設計的。

但大多數真實專案都不那麼清楚。這就是事情變得有趣的地方。

Database and Data Modeling

Directus

Directus 使用「資料庫優先」方法。你通過 Directus UI 或直接在你的資料庫中定義你的模式 -- 兩者都有效。管理應用程式會根據你的模式自動生成表單、關係和驗證。想要一個 many-to-many 關係在 articles 和 tags 之間？建立連接表（或讓 Directus 建立它），管理 UI 會自動呈現一個很好的標籤選擇器。

我欣賞的一點：Directus 不會在你的表上創建自己的抽象層。你的表名、列名和關係完全是你定義的內容。系統表（前綴為 directus_）位於你的資料旁邊，但不會干擾它。

2026 年支持的資料庫：

  • PostgreSQL 12+
  • MySQL 8+
  • MariaDB 10.5+
  • MS SQL 2019+
  • SQLite 3+
  • CockroachDB 22+
  • Oracle 19c+

Supabase

Supabase 是 PostgreSQL。就這樣。你獲得一個完整的 Postgres 實例，帶有如 PostGIS、pgvector、pg_cron 和其他數百個擴展。模式管理通過儀表板的 SQL 編輯器、表編輯器 UI 或通過 Supabase CLI 的遷移進行。

Supabase 中的遷移工作流已經成熟了許多。CLI 生成遷移檔案，你可以使用 supabase db diff 來捕捉通過儀表板進行的模式更改。在 2026 年，他們還添加了分支 -- 資料庫分支允許你在合併到生產環境之前在隔離環境中測試模式更改。

-- Supabase migration example
create table public.articles (
  id uuid default gen_random_uuid() primary key,
  title text not null,
  slug text unique not null,
  content jsonb,
  published_at timestamptz,
  author_id uuid references auth.users(id),
  created_at timestamptz default now()
);

alter table public.articles enable row level security;

create policy "Published articles are viewable by everyone"
  on public.articles for select
  using (published_at is not null and published_at <= now());

行級安全（RLS）模型既是 Supabase 的超能力，也是其最陡峭的學習曲線。稍後會詳細介紹。

功能 Directus Supabase
資料庫引擎 PostgreSQL、MySQL、MariaDB、MS SQL、SQLite、CockroachDB、Oracle 僅 PostgreSQL
模式管理 GUI + 直接 SQL GUI + SQL 編輯器 + CLI 遷移
資料庫分支 未內置（使用單獨的實例） 是的（原生，自 2024 年末）
擴展 取決於選擇的資料庫 60+ Postgres 擴展
向量/AI 支持 通過擴展 pgvector 內置
直接資料庫訪問 始終完整訪問 始終完整訪問

API Layer Comparison

Directus APIs

Directus 從你的模式自動生成 REST 和 GraphQL API。REST API 遵循可預測的模式：

# Get all articles with author relationship
GET /items/articles?fields=*,author.name&filter[status][_eq]=published&sort=-published_at&limit=10

過濾系統很有表現力。你可以進行嵌套關係過濾、聚合，甚至地理查詢。SDK 很好地包裝了所有這些：

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

const client = createDirectus('https://your-instance.com').with(rest());

const articles = await client.request(
  readItems('articles', {
    fields: ['*', { author: ['name', 'avatar'] }],
    filter: { status: { _eq: 'published' } },
    sort: ['-published_at'],
    limit: 10,
  })
);

Directus 11（2026 年當前穩定版本）中的 TypeScript SDK 在類型推論上有了很大改進，儘管你仍需要從你的模式生成類型以獲得完整的類型安全性。

Supabase APIs

Supabase 通過 PostgREST 生成 REST API，並提供一個感覺更像 ORM 的 JavaScript 客戶端庫：

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);

const { data: articles, error } = await supabase
  .from('articles')
  .select('*, author:profiles(name, avatar_url)')
  .eq('status', 'published')
  .order('published_at', { ascending: false })
  .limit(10);

Supabase 開箱即用不提供 GraphQL。他們曾經有 pg_graphql，它仍然可作為擴展使用，但主要 DX 是他們的 JS 客戶端和 REST API。說實話？使用 Supabase 時我不懷念 GraphQL。帶有關係連接的 select 語法涵蓋了 95% 的用例。

Supabase 拔得頭籌的一個領域：通過 WebSocket 的實時訂閱和用於伺服器端邏輯的邊緣函數。Directus 有 Flows（他們的自動化引擎），但它不像擁有完整的無伺服器函數運行時那樣。

Directus vs Supabase in 2026: Choosing Your Backend - architecture

Content Management Experience

這是 Directus 完全主導的地方。甚至不接近。

Directus 的管理應用程式是為內容團隊設計的。你可以獲得：

  • 自訂佈局：看板、日曆、地圖、用於集合瀏覽的分割視圖
  • WYSIWYG 和塊編輯器：Directus 11 中的塊編輯器真的很好
  • 翻譯支持：內置的 i18n，帶有並排翻譯介面
  • 修訂歷史：完整的內容版本控制，帶有差異視圖
  • 即時預覽：配置預覽 URL，以便編輯者在發布前看到更改
  • 細粒度許可權：基於角色的訪問控制，細至個別欄位
  • 自訂儀表板：內容團隊的分析和概覽面板

Supabase 的表編輯器是……一個表編輯器。對於想要他們資料庫的 GUI 的開發人員來說很好。對於需要更新主頁英雄部分的行銷團隊來說很糟糕。如果你在構建一個以內容為驅動的網站並且你的編輯者將直接接觸後端，Directus 默認獲勝。

我見過團隊嘗試在 Supabase 之上構建自訂管理 UI 以進行內容編輯。它有效，但你基本上是從頭開始構建 CMS。那是 Directus 在第一天就給你的幾個月工作。

如果你正在尋找適用於你的網站的適當無頭 CMS 設置，我們的團隊定期在 headless CMS projects 中使用 Directus -- 這是我們對以內容為重的網站的首選建議之一。

Authentication and Authorization

Supabase Auth

Supabase Auth 是一個功能齊全的身份驗證系統。電子郵件/密碼、魔法連結、OAuth（Google、GitHub、Apple 等）、電話/短信和 SAML SSO 都內置其中。它直接與 PostgreSQL 的行級安全集成，這意味著你的身份驗證規則存在於資料庫本身中。

-- Only allow users to read their own profiles
create policy "Users can view own profile"
  on profiles for select
  using (auth.uid() = id);

-- Allow users to update their own profile
create policy "Users can update own profile"
  on profiles for update
  using (auth.uid() = id);

一旦你理解了這個模型，它就很優雅，但 RLS 政策可能會很快變得複雜。調試為什麼查詢因為缺少政策而返回空結果是你學會接受的樂趣之一。

Directus Auth

Directus 為自己的管理使用者處理身份驗證，也支持通過 OpenID Connect、SAML、LDAP 和 OAuth2 的外部 SSO。對於前端應用程式使用者，你通常會使用帶有自訂角色的 Directus 使用者系統。

Directus 中的許可權模型是 GUI 驅動的。你創建角色，然後為每個角色配置每個集合的 CRUD 許可權，可選地帶有欄位級和項目級規則。這比 RLS 政策更視覺化，可以說更容易推理，但對於複雜的應用程式邏輯靈活性較低。

對於最主要關注點是終端使用者身份驗證的應用程式（想想 SaaS 應用程式），Supabase 的身份驗證系統要成熟得多。對於管理內容團隊訪問，Directus 的角色系統更適合。

Realtime Capabilities

Supabase 的實時引擎已可用於生產，並處理存在、廣播和資料庫更改監聽器：

const channel = supabase
  .channel('articles')
  .on('postgres_changes', {
    event: 'INSERT',
    schema: 'public',
    table: 'articles',
  }, (payload) => {
    console.log('New article:', payload.new);
  })
  .subscribe();

這對於聊天應用程式、協作工具、實時儀表板和通知系統非常有用。

Directus 添加了 WebSocket 支持，並通過其 GraphQL 訂閱端點提供實時訂閱。它有效，但不是相同的成熟度級別。Directus Realtime 對於「在內容更改時通知我」的場景很好，但不是為高頻協作應用程式構建的。

Self-Hosting and Infrastructure

兩個工具都是開源的，可以自行託管。

Directus 是一個 Node.js 應用程式，分佈為 npm 包和 Docker 映像。自行託管很直接 -- 將其指向你的資料庫，配置環境變數，你就在運行了。我已經在 Railway、Fly.io、AWS ECS 和普通 VPS 實例上部署過它，沒有問題。

Supabase 自行託管涉及更多。完整堆疊包括 PostgreSQL、PostgREST、GoTrue（身份驗證）、Realtime、Storage、Kong（API 閘道）和 Studio 儀表板。他們的 Docker Compose 設置適用於開發，但生產自行託管需要更多的運營知識。大多數團隊選擇 Supabase 的託管平台，除非他們有特定的合規要求。

方面 Directus 自行託管 Supabase 自行託管
複雜性 低-中等（單個 Node.js 應用程式 + 資料庫） 高（7+ 服務）
Docker 支持 官方映像、簡單 Docker Compose、複雜
最少資源 1 vCPU、1GB RAM 4 vCPU、8GB RAM（所有服務）
社群指南 廣泛 不斷增長但不那麼成熟
託管替代方案 Directus Cloud Supabase Platform

Pricing Breakdown 2026

讓我們談論金錢。這些是 2026 年初目前發佈的價格。

Directus Cloud

計畫 價格 包括
Community（自行託管） 免費 所有內容，自行管理
Standard $99/月 1 個專案、100K API 請求、5GB 資產
Professional $399/月 自訂網域、更多資源、優先級支持
Enterprise 自訂 SSO、SLA、專用基礎設施

Supabase Platform

計畫 價格 包括
Free $0 500MB 資料庫、1GB 儲存、50K 身份驗證使用者、500K 邊緣函數呼叫
Pro $25/月 8GB 資料庫、100GB 儲存、100K 身份驗證使用者、2M 邊緣函數呼叫
Team $599/月 優先級支持、SOC2、每日備份、28 天日誌保留期
Enterprise 自訂 SLA、專用支持、自訂合約

價格差異是巨大的。Supabase 的免費層對於副業專案和 MVP 來說確實是可用的。Directus Cloud 的進入點在 $99/月時，對於實驗來說太陡峭了 -- 但在 $5/月 VPS 上自行託管 Directus 對於小型專案完全有效。

對於構建應用程式的新創公司，Supabase 的 $25/月 Pro 計畫給了你很多。對於運行以內容為重的網站的業務，Directus 自行託管加上託管 PostgreSQL 實例可能花費 $20-50/月。

Developer Experience

我構建了很多 Next.js projects 和 Astro sites，所以框架集成對我來說很重要。

Directus DX

  • TypeScript SDK 很好，每個版本都在改進
  • 模式類型可以從你的實例生成
  • 用於自訂端點、鉤子、面板和介面的擴展系統
  • Flows（視覺自動化）可以取代簡單的後端邏輯
  • 管理應用程式可以使用自訂模組和佈局進行自訂
  • 內置於資產交付 API 中的影像轉換

Supabase DX

  • 從你的模式自動生成的 TypeScript 類型（supabase gen types typescript）
  • 使用 supabase start 進行本地開發（在 Docker 中運行所有內容）
  • 邊緣函數（基於 Deno）用於伺服器端邏輯
  • 帶有 pgvector 的內置向量搜索，用於 AI 功能
  • CLI 驅動的工作流，包括遷移、分支和 CI/CD
  • Vercel/Netlify 集成，用於環境變數同步

兩者都有紮實的文檔。Supabase 的文檔特別組織得當，具有特定框架的指南（Next.js、Nuxt、SvelteKit、Flutter 等）。Directus 的文檔很完整，但有時滯後於最新的 SDK 更改。

When to Use Each One

在廣泛使用兩者後，這是我的決策框架：

在以下情況下選擇 Directus：

  • 內容編輯需要一個精拋的管理介面
  • 你在構建行銷網站、博客或編輯平台
  • 你需要多語言內容管理
  • 你現有的資料庫需要管理 UI
  • 內容工作流（草稿、評論、批准）很重要
  • 你想使用 MySQL、MariaDB 或另一個非 PostgreSQL 資料庫

在以下情況下選擇 Supabase：

  • 你在構建一個面向使用者的應用程式（SaaS、市場、社交）
  • 你需要身份驗證和使用者管理
  • 實時功能是核心要求
  • 你想要用於伺服器端邏輯的邊緣函數
  • AI/向量搜索是你的路線圖的一部分
  • 你想要從想法到已部署應用程式的最快路徑

同時使用兩者：

這並不瘋狂。我構建過系統，其中 Supabase 處理使用者身份驗證、應用程式資料和實時功能，而 Directus 管理行銷網站內容、博客和文檔。他們可以共享相同的 PostgreSQL 實例或使用單獨的資料庫。責任的分離實際上使架構更清潔。

如果你試圖為你的專案確定正確的後端架構，這正是我們的團隊所做的 -- 請隨時 reach out 並討論你的具體情況。

FAQ

Directus 能否替代 Supabase 作為 Web 應用程式的後端？ 部分上可以。Directus 為你提供資料庫 API 和使用者管理，所以對於簡單的 CRUD 應用程式，它可以有效。但你會錯過 Supabase 的內置身份驗證系統、實時訂閱、邊緣函數和檔案存儲服務。Directus 針對內容管理進行了優化，而不是應用程式後端工作負載。對於主要包含內容操作的簡單應用程式，Directus 很好。對於任何具有使用者身份驗證流、實時功能或複雜伺服器端邏輯的內容，你會想要 Supabase 或類似的 BaaS。

Supabase 是否適合作為無頭 CMS？ 它可以起到這個作用，但需要大量自訂工作。你需要為內容編輯者構建自己的管理介面、分開處理影像轉換、手動實現內容版本控制，並創建自己的預覽系統。團隊已經用 Supabase + 自訂 React 管理面板做過這個，但你在重新發明 Directus（或 Strapi 或 Payload）為你開箱即用提供的內容。如果內容管理是你的主要需求，使用專用的無頭 CMS。

哪個更適合 Next.js 應用程式？ 兩者都與 Next.js 很好地集成。Supabase 有官方的 Next.js 幫手（@supabase/ssr），它在伺服器元件和中間件中處理身份驗證 cookie 管理。Directus 也與 Next.js 一樣有效 -- 你通過 SDK 在伺服器元件中獲取資料，並為性能使用 ISR 或 SSG。對於帶有博客的行銷網站，我會將 Next.js 與 Directus 配對。對於帶有使用者帳戶的 SaaS 應用程式，使用 Supabase 的 Next.js。我們在我們的 Next.js development practice 中深入介紹了這一點。

我能免費自行託管 Directus 和 Supabase 嗎？ 是的。兩者都是開源的，具有寬鬆許可證（Directus 使用 BSL 1.1 許可證，在 3 年後轉換為 Apache 2.0；Supabase 對大多數元件使用 Apache 2.0）。Directus 更容易自行託管 -- 它是一個單一的 Node.js 應用程式。Supabase 自行託管需要運行多個服務（PostgreSQL、PostgREST、GoTrue、Realtime、Storage、Kong）。對於 Supabase，大多數開發人員使用託管平台並為自己節省運營開銷。

Directus 和 Supabase 如何處理檔案存儲和媒體？ Directus 有一個內置的資產管理系統，具有即時影像轉換（調整大小、裁剪、格式轉換）。你通過管理 UI 或 API 上傳檔案，並通過 URL 參數請求轉換後的版本。Supabase Storage 是一個 S3 相容的檔案存儲服務，具有基於 RLS 的訪問控制。它很好地處理上傳和下載，但沒有內置的影像轉換 -- 你可以將其與 Imgix、Cloudinary 或 Supabase 自己的影像轉換（在 2025 年以測試版啟動）配對。

關於性能和可擴展性呢？ Supabase 的基礎設施構建在 AWS 上，並通過 Supavisor 進行連接池，可以處理大量流量。他們的 Pro 計畫資料庫可以擴展到 64GB RAM 實例。Directus 性能在很大程度上取決於你的託管設置和資料庫。通過正確的快取（Redis、CDN），Directus 可以很好地處理高流量，但你負責基礎設施。在基準測試中，兩者都可以通過適當的資源處理每秒數千個請求。瓶頸幾乎總是資料庫，而不是 API 層。

對於具有非技術成員的團隊，Directus 還是 Supabase 更好？ Directus，毫無疑問。其管理介面是為非開發人員設計的。你可以創建自訂儀表板、設置內容批准工作流和按角色限制訪問 -- 所有這些都無需編寫程式碼。Supabase 的儀表板是開發人員工具。你的行銷團隊不會寫 SQL 來更新登陸頁面。如果非技術團隊成員需要管理資料，Directus 的 UI 是正確的選擇。

我以後能否從一個遷移到另一個？ 由於兩者都與 PostgreSQL 相容（Directus 支持其他資料庫），遷移是可行的，但並不瑣碎。如果你使用 PostgreSQL 在 Directus 上，並想添加 Supabase，你可以將 Supabase 指向你的現有資料庫或遷移資料。Directus 系統表和 Supabase 的身份驗證模式需要共存或分離。朝另一個方向走 -- 在 Supabase 資料庫之上添加 Directus -- 實際上是一個記錄良好的模式。Directus 可以內省現有表並創建其管理層，而不修改你的資料模式。