Wenn du 2026 ein Headless-CMS-Projekt aufbaust und deine Optionen auf Payload CMS und Directus eingegrenzt hast, gratuliere — du hast einen guten Geschmack. Beide sind Open-Source, selbst zu hosten und auf Node.js aufgebaut. Beide haben aktive Communitys und entwickeln Features schnell. Aber sie repräsentieren grundlegend unterschiedliche Philosophien, wie dein Content-Schema entstehen sollte, und dieser Unterschied wird sich durch jede Entscheidung in deinem Projekt ziehen.

Ich habe in den letzten zwei Jahren Produktionsseiten mit beiden ausgeliefert. Hier ist, was ich wirklich denke, nicht das, was die Marketing-Seiten sagen.

Inhaltsverzeichnis

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

Die Kern-Philosophie-Aufspaltung

Lass mich das klar aussprechen, denn es ist das Wichtigste, was man verstehen muss:

Payload CMS ist Code-First. Du definierst dein Schema in TypeScript-Config-Dateien. Die Datenbank passt sich deinem Code an.

Directus ist Database-First. Du kannst auf eine vorhandene Datenbank zeigen und es führt eine Introspection des Schemas durch. Die Admin-UI passt sich zu deiner Datenbank an.

Kein Ansatz ist objektiv besser. Aber einer wird für dein Projekt dramatisch besser sein, und das falsch zu machen bedeutet später Schmerzen.

Wenn du ein Entwickler bist, der ein Greenfield-Projekt aufbaut und dein CMS-Schema versionskontrolliert neben deinem Anwendungscode haben möchte, wird sich Payload wie zu Hause anfühlen. Wenn du eine vorhandene PostgreSQL-Datenbank mit 200 Tabellen hast und eine Content-Management-Schicht darauf benötigst, wird Directus dir Wochen ersparen.

Schema-Design: Code-First vs. Database-First

Payloads Code-First-Ansatz

In Payload 3.x (die aktuelle Hauptversion ab 2026) definierst du Collections in TypeScript-Config-Dateien:

// 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',
    },
  ],
}

Diese Config ist deine Source of Truth. Wenn Payload startet, generiert es automatisch Datenbank-Migrationen (Payload 3.x nutzt Drizzle ORM unter der Haube mit PostgreSQL- oder SQLite-Unterstützung und unterstützt immer noch MongoDB). Dein Schema lebt in Git. Du überprüfst Schema-Änderungen in PRs. Es ist der gleiche Workflow, den du für Anwendungscode verwenden würdest, und das ist der Sinn.

Payload generiert auch automatisch TypeScript-Typen aus diesen Configs. Wenn du also posts in deinem Next.js-Frontend abfragst, bekommst du volle Typ-Sicherheit, ohne separate Typ-Definitionen zu pflegen.

Directus' Database-First-Ansatz

Directus nimmt die gegensätzliche Position ein. Du kannst:

  1. Directus auf eine vorhandene Datenbank zeigen lassen und es liest das Schema
  2. Collections über die Admin-UI erstellen, die SQL-Migrationen generiert
  3. Das Directus SDK verwenden, um das Schema programmgesteuert zu verwalten
// Eine Collection über das Directus SDK erstellen
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 (Ende 2025 veröffentlicht) verbesserte die Schema-Migrations-Tools erheblich. Du kannst jetzt Schema-Snapshots als YAML-Dateien exportieren und importieren, was die Versionskontrolle praktischer macht als früher:

# Aktuelles Schema exportieren
npx directus schema snapshot ./schema-snapshot.yaml

# Schema-Diff auf eine andere Umgebung anwenden
npx directus schema apply ./schema-snapshot.yaml

Aber ehrlich gesagt: Auch mit diesen Verbesserungen fühlt sich Directus' Schema-Management nicht so natürlich in einem Git-Workflow an wie Payloads Ansatz. Du machst einen Snapshot des Zustands statt die Absicht zu deklarieren.

Schema-Vergleichstabelle

Aspekt Payload CMS Directus
Schema Source of Truth TypeScript-Config-Dateien Datenbank selbst
Schema-Versionierung Nativer Git-Workflow YAML-Snapshots (verbessert in v11)
Unterstützung vorhandener Datenbanken Begrenzt (Migrations-Pfad) Ausgezeichnet (Introspection)
Auto-generierte Typen Ja, aus Config Ja, via SDK + CLI
Datenbankunterstützung PostgreSQL, SQLite, MongoDB PostgreSQL, MySQL, MariaDB, SQLite, MS SQL, CockroachDB, OracleDB
ORM / Query-Schicht Drizzle ORM (v3) Custom Query Engine (Knex-basiert)
Migrations-Generierung Automatisch aus Config-Änderungen Schema-Diff-Snapshots

TypeScript und Developer Experience

Payloads TypeScript-Story

Payload ist TypeScript bis ins Mark. Das ganze Projekt ist in TypeScript geschrieben, in TypeScript konfiguriert und generiert TypeScript. Wenn du payload generate:types ausführst, bekommst du Interfaces für jede Collection:

// Auto-generiert
export interface Post {
  id: string
  title: string
  content?: RichTextContent
  author?: string | User
  publishedAt?: string
  status?: 'draft' | 'published'
  createdAt: string
  updatedAt: string
}

Diese Typen fließen durch zu deiner Local API, REST-API-Responses und GraphQL-Abfragen. In Payload 3.x, da es in deiner Next.js-App läuft, kannst du diese Typen direkt importieren und verwenden. Kein separates SDK nötig. Keine API-Calls für serverseitiges Rendering — du fragst die Datenbank direkt ab:

// In einer Next.js Server Component
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 ist vollständig als Post[] typisiert
  
  return <PostList posts={posts.docs} />
}

Das ist wirklich ausgezeichnete DX. Kein Netzwerk-Hop, volle Typen, und es ist einfach... Funktionen.

Directus' TypeScript-Story

Directus hat seine TypeScript-Unterstützung erheblich verbessert. Das @directus/sdk-Paket unterstützt generische Typ-Parameter:

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.*'],
  })
)

Der Haken? Du musst diese Typ-Definitionen selbst schreiben und warten (oder Community-Tools wie directus-typescript-gen zum Generieren verwenden). Die Typen werden nicht auf die gleiche erste-Klasse-Weise aus dem Schema abgeleitet wie Payload das tut. Das ist der Trade-off des Database-First-Ansatzes: Die Datenbank weiß nichts von TypeScript.

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

API-Schicht und Query-Fähigkeiten

Beide generieren REST- und GraphQL-APIs, aber mit unterschiedlichen Geschmäckern.

Payload bietet dir:

  • REST API mit Tiefenkontrolle für Relationships
  • GraphQL API (auto-generiert aus deiner Config)
  • Local API (direkte Datenbankabfragen, kein HTTP-Overhead)
  • Vollständige Query-Operatoren: equals, not_equals, greater_than, in, contains, etc.

Directus bietet dir:

  • REST API mit granularer Feldauswahl
  • GraphQL API (auto-generiert aus Schema-Introspection)
  • Directus SDK (wrapped REST, typisiert wenn du Interfaces bereitstellst)
  • Umfangreiches Filtern mit _eq, _neq, _gt, _in, _contains, logische _and/_or-Operatoren
  • Aggregations-Abfragen in die API eingebaut (count, sum, avg, etc.)

Directus hat einen leichten Vorteil bei API-Flexibilität für komplexe Abfragen, besonders Aggregationen. Wenn du GROUP BY-ähnliche Abfragen über die API machen musst, handhabt Directus das nativ. Mit Payload würdest du normalerweise auf die Drizzle-ORM-Schicht herabsinken oder einen benutzerdefinierten Endpunkt schreiben.

Payloads Killer-Vorteil ist die Local API. Wenn dein CMS und dein Next.js-Frontend der gleiche Prozess sind, springst du HTTP komplett über. Für serverseitig gerenderter Seiten bedeutet das schnellere Builds und geringere Latenz.

Admin-Panel und Content-Bearbeitung

Payloads 3.x Admin-Panel ist mit React gebaut und wird als Teil deiner Next.js-Anwendung ausgeliefert. Es ist anpassbar mit React-Komponenten — du kannst praktisch jeden Teil der UI überschreiben. Der Block-basierte Rich-Text-Editor (auf Lexical ab v3 aufgebaut) ist mächtig und erweiterbar.

Directus' Admin-Panel ist eine eigenständige Vue.js-Anwendung (Directus Data Studio). Es ist poliert, hat ein starkes visuelles Design, und nicht-technische Benutzer verstehen es normalerweise schnell. Der Flows/Automation-Builder in Directus ist merklich visueller und zugänglicher als Payloads Hooks-System.

Feature Payload CMS Directus
Admin-Framework React (Next.js) Vue.js (eigenständig)
Rich-Text-Editor Lexical-basiert TipTap / WYSIWYG
Benutzerdefinierte Felder React-Komponenten Vue-Erweiterungen
Workflow/Automation Hooks + Custom Endpoints Directus Flows (visueller Builder)
Lokalisierung Eingebaute feldbasierte i18n Eingebaute feldbasierte i18n
Content-Versionierung Draft/Publish + Versionen Content-Versionierung + Revisionen
Datei-Management Eingebaute Media Library Eingebaute Media Library mit Transforms

Hier meine ehrliche Meinung: Für entwickler-schwere Teams ist Payloads Admin natürlicher zu erweitern, weil du React schreibst. Für Teams, wo Content-Editoren die primären Benutzer sind und du reibungsfreie UX möchtest, ist Directus' Admin-Panel leicht approachbarer out-of-the-box.

Authentifizierung und Zugriffskontrolle

Beide Systeme haben reife Auth, aber sie funktionieren unterschiedlich.

Payload nutzt Collection-basierte Auth. Du markierst eine Collection als Auth-Collection (typischerweise users), und sie bekommt Login, Registrierung, Passwort-Zurücksetzen, E-Mail-Verifizierung und JWT/Cookie-basierte Sessions. Zugriffskontrolle wird pro Collection und pro Feld mit Funktionen definiert:

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

Das ist unglaublich mächtig. Zugriffskontroll-Funktionen erhalten den vollständigen Request-Kontext, so dass du jedes Muster implementieren kannst — RBAC, ABAC, Multi-Tenancy, Row-Level Security.

Directus nutzt ein rollenbasiertes Berechtigungssystem, das über die Admin-UI konfiguriert wird. Du erstellst Rollen, zuordnest granulare Berechtigungen (CRUDS pro Collection) und fügst benutzerdefinierte Berechtigungen mit Filtern hinzu. Es ist visuell und intuitiv, aber weniger flexibel für komplexe Muster, die nicht zum Rollen-Modell passen.

Für die meisten Projekte reichen beide aus. Für Multi-Tenant-SaaS oder komplexe Autorisierungs-Logik ist Payloads Code-basierte Zugriffskontrolle unschlagbar.

Leistung und Skalierbarkeit

Ich habe beide unter realistischen Bedingungen Last-getestet. Hier ist das, was ich mit PostgreSQL-Backends beobachtet habe:

Metrik Payload CMS 3.x Directus 11
Einfaches Lesen (einzelnes Item) ~2-5ms Local API, ~15-25ms REST ~15-30ms REST
List Query (100 Items, keine Relations) ~8-15ms Local API, ~30-50ms REST ~25-50ms REST
List Query (100 Items, 2 Ebenen tief) ~20-40ms Local API, ~60-100ms REST ~50-120ms REST
Kaltstartzeit ~3-6s (Next.js Startup) ~2-4s (eigenständig)
Memory-Baseline ~200-350MB (mit Next.js) ~150-250MB

Payloads Local-API-Vorteil ist real und signifikant für SSR/SSG-Workloads. Wenn du 10.000 statische Seiten generierst, addiert sich das Überspringen von HTTP für jede Abfrage schnell auf.

Directus ist aber kein Schnarchschütze. Es verarbeitet High-Throughput-REST-Workloads gut, und sein Caching-Layer (Redis-unterstützt) ist reif.

Deployment und Hosting

Payload 3.x ist eine Next.js-Anwendung, was bedeutet, dass du sie überall dort einsetzen kannst, wo Next.js läuft: Vercel, Netlify, AWS, Docker, etc. Payload Cloud (ihr verwaltetes Hosting) beginnt ab $30/Monat für Produktionsprojekte ab Anfang 2026.

Directus läuft als eigenständige Node.js-Anwendung. Docker ist die empfohlene Deployment-Methode. Directus Cloud beginnt bei $29/Monat. Selbst-Hosting auf einem VPS ist unkompliziert — es ist einfach ein Docker-Container, der eine Datenbankverbindung benötigt.

Eine Sache ist erwähnenswert: Weil Payload 3.x deine Next.js-App ist, deployen dein CMS und Frontend zusammen. Das vereinfacht die Infrastruktur, aber bedeutet, dass dein CMS Admin-Panel mit deinem Frontend skaliert. Bei hochfrequenten Seiten, bei denen Frontend und CMS sehr unterschiedliche Skalierungsanforderungen haben, möchtest du vielleicht erwägen, sie separat auszuführen.

Directus, als eigenständiger Service, separiert diese Bedenken natürlich. Dein Frontend (egal ob Next.js, Astro oder irgendetwas anderes) verbindet sich über HTTP mit Directus. Das ist eine traditionellere Headless-Architektur.

Bei Social Animal haben wir beide Architekturen für Kunden deployed. Der Payload-in-Next.js-Ansatz funktioniert wunderbar für die meisten Marketing-Seiten und mittelgroßen Anwendungen. Für Enterprise-Setups mit mehreren Frontend-Consumern kann der getrennte Directus-Ansatz sauberer sein.

Preise und Lizenzierung in 2026

Payload CMS Directus
Lizenz MIT GPL-3.0 (mit BSL für Cloud-Features)
Selbst-gehostete Kosten Kostenlos Kostenlos
Cloud-Hosting Ab $30/Monat (Payload Cloud) Ab $29/Monat (Directus Cloud)
Enterprise-Tier Benutzerdefinierte Preisgestaltung Benutzerdefinierte Preisgestaltung (beginnt ~$1.500/Monat)
Premium-Features Einige Features nur für Cloud Directus+ Abonnement ($99/Monat für Marketplace-Erweiterungen)

Beide sind wirklich Open-Source zum Selbst-Hosten. Payloads MIT-Lizenz ist permissiver — du kannst sie in kommerzielle Produkte einbetten ohne Einschränkungen. Directus' GPL-3.0-Lizenz bedeutet, dass abgeleitete Arbeiten auch GPL sein müssen, was für SaaS-Produkte wichtig sein kann.

Directus führte Directus+ Ende 2025 ein, ein Abonnement, das Premium-Marketplace-Erweiterungen und priorisierte Unterstützung freischaltet. Es ist optional, aber einige der fortgeschritteneren Erweiterungen (wie der AI-Content-Assistent) sind hinter dieser Paywall.

Wann man welches wählt

Wähle Payload CMS wenn:

  • Du ein neues Projekt von Grund auf aufbaust (Greenfield)
  • Dein Team TypeScript-schwer ist und Schema-als-Code möchte
  • Du Next.js nutzt und die engste mögliche Integration möchtest
  • Du komplexe, Code-definierte Zugriffskontrolle benötigst
  • Du alles in einer deployable Unit möchtest
  • Du MIT-Lizenzierung bevorzugst

Wähle Directus wenn:

  • Du eine vorhandene Datenbank hast, die du verwalten musst
  • Dein Team Nicht-Entwickler einschließt, die Schemas ändern müssen
  • Du mehrere Frontends (Web, Mobile, IoT) von einem CMS aus unterstützen musst
  • Du einen visuellen Automation/Flow-Builder brauchst
  • Du breite Datenbankunterstützung brauchst (MySQL, MSSQL, Oracle, etc.)
  • Du das CMS als einen separaten, unabhängigen Service bevorzugst

Wenn du diese Optionen für ein Headless-Projekt abwägst und eine zweite Meinung möchtest, wir bieten Headless-CMS-Architektur-Consulting an und können dir helfen, das richtige Werkzeug zu wählen, bevor du drei Monate in das falsche bist.

Für Projekte, die Astro als Frontend-Framework nutzen, passt sich Directus' eigenständiger API-Ansatz natürlich an, da Astro Daten zum Build-Zeitpunkt oder über Server-Endpunkte abruft. Payload funktioniert auch, aber du verlierst den Local-API-Vorteil, da Astro und Payload separate Prozesse wären.

Häufig gestellte Fragen

Ist Payload CMS 2026 wirklich kostenlos? Ja. Payload CMS ist MIT-lizenziert und komplett kostenlos selbst zu hosten. Payload Cloud ist ihr bezahltes verwaltetes Hosting-Service, aber das CMS selbst — einschließlich all der Core-Features — ist Open Source. Es gibt keine Feature-Gates bei der selbst-gehosteten Version.

Kann Directus mit einer vorhandenen Datenbank arbeiten, ohne sie zu ändern? Größtenteils ja. Directus kann eine vorhandene Datenbank introspektieren und eine Management-Schicht darauf erstellen. Es fügt ein paar System-Tabellen hinzu (mit Präfix directus_) für seine eigene Konfiguration, aber es ändert deine bestehenden Tabellen nicht. Das ist einer seiner stärksten Unterscheidungsmerkmale.

Welches ist besser für einen Solo-Entwickler? Payload CMS ist üblicherweise der Favorit unter Solo-Entwicklern, die sich mit TypeScript auskennen. Der Code-First-Workflow bedeutet, dass du Collections schnell einrichten kannst, und die auto-generierten Typen reduzieren Boilerplate. Directus ist besser, wenn du eine visuelle Schnittstelle für schnelles Schema-Prototyping willst, ohne Config-Dateien zu schreiben.

Kann ich Payload CMS ohne Next.js verwenden? Ab Payload 3.x ist Next.js der primäre Adapter und das Admin-Panel läuft auf Next.js. Allerdings funktionieren die REST- und GraphQL-APIs mit jedem Frontend. Du bist nicht an Next.js für deine Verbraucher-Seite gebunden — du brauchst nur Next.js zum Ausführen des Payload-Admin. Es gab Community-Diskussionen über zusätzliche Adapter (wie Nuxt), aber nichts Offizielles bisher.

Wie behandelt Directus Content-Lokalisierung? Directus unterstützt feldbasierte Übersetzungen. Du markierst Felder als übersetzbar, konfigurierst deine Sprachen, und Directus verwaltet das Speichern von Übersetzungen in einer Related-Tabelle. Die API ermöglicht es dir, Content in spezifischen Sprachen über die ?fields- und Sprach-Parameter anzufordern. Es ist gut umgesetzt und jahrelang stabil.

Welches hat bessere Plugin-/Erweiterungs-Unterstützung? Directus hat einen größeren Erweiterungs-Marketplace, besonders mit den Directus+ Ergänzungen. Du kannst benutzerdefinierte Interfaces, Displays, Endpoints, Hooks und Module erstellen. Payloads Erweiterungs-Modell basiert auf React-Komponenten-Überschreibungen und Plugins — es ist mächtig, aber die Ökosphäre ist kleiner. Payloads Plugins neigen dazu, fokussierter zu sein (SEO-Plugin, Form-Builder, Redirects) während Directus-Erweiterungen ein breiter Bereich abdecken.

Gibt es einen Leistungsunterschied bei großen Datasets? Bei Datasets mit Millionen Reihen funktionieren beide gut, wenn sie richtig indexiert sind. Directus hat einen leichten Vorteil bei Raw-Query-Flexibilität, da es SQL direkter aus API-Abfragen generiert. Payloads Drizzle-ORM-Schicht ist effizient, aber fügt kleine Abstraktionskosten hinzu. In der Praxis wichtiger als welches CMS du wählst ist deine Datenbank-Tuning. Beide unterstützen Connection Pooling und können mit Read-Replicas arbeiten.

Kann ich später von einem zum anderen migrieren? Du kannst, aber es ist nicht trivial. Die Content-Daten selbst (gespeichert in PostgreSQL für beide) können mit Standard-Datenbank-Tools migriert werden. Der schwierigere Teil ist die Neu-Erstellung deiner Schema-Definitionen, Zugriffskontroll-Regeln und beliebige benutzerdefinierte Logik. Wenn du für eine Headless-Architektur aufbaust, wird das Freihalten deines Frontends von CMS-spezifischen APIs (mit einer Abstraktions-Schicht) jede zukünftige CMS-Migration erheblich leichter machen.