Ihr Deploy wird fertig, die Website geht live, und drei Wochen später meldet sich Ihr Content-Team: Die Image-Uploads laufen ins Timeout, verschachtelte Kategorien lassen sich nicht speichern, und die API-Response klettert über 800ms. Ich habe dieses Szenario in den letzten zwei Jahren mit Directus, Payload und Supabase in Production-Projekten durchlaufen — gleiche Symptome, jedes Mal unterschiedliche Ursachen. Die Antwort hängt von Dingen ab, die die Landing Pages überspringen: wie Ihre Redakteure Workflows strukturieren, wie Ihr Relationengraph wirklich aussieht, und ob Sie diesen Stack noch nutzen, wenn die Series A geschlossen wird. Hier ist das Framework, das bestimmt, welches Backend Ihre nächsten sechs Sprints übersteht.

Das ist kein Feature-Checklisten-Vergleich. Es ist das Decision-Framework, das ich tatsächlich nutze, wenn ich Projekte bei Social Animal scope, verfeinert durch Dutzende von Headless-Builds. Am Ende wissen Sie, welches Tool zu Ihrer spezifischen Situation passt, ohne in Selbstzweifel zu verfallen.

Inhaltsverzeichnis

Directus vs Payload vs Supabase: Which CMS Backend to Use in 2026 - architecture

Die Kernidentität jedes Tools

Bevor wir in die Details gehen, müssen Sie verstehen, was jedes Tool tatsächlich im Kern ist, denn die Überschneidungen in den Feature-Sets können irreführend sein.

Directus ist ein datenbankzentriertes Headless-CMS. Es umhüllt eine existierende SQL-Datenbank (Postgres, MySQL, SQLite, MS SQL, MariaDB, CockroachDB) mit einer auto-generierten API und einem polierten Admin-Panel. Sie designen Ihre Datenbank, Directus introspiziert sie und gibt Ihnen eine UI. Es ist in TypeScript geschrieben und läuft auf Node.js.

Payload ist ein Code-zentriertes Headless-CMS, das auf Next.js aufbaut (ab Payload 3.0). Sie definieren Collections und Fields in TypeScript-Konfigurationsdateien, und Payload generiert das Datenbankschema, die Admin-UI, API-Endpoints und TypeScript-Typen aus dieser Konfiguration. Es nutzt MongoDB oder Postgres als Datenbankschicht.

Supabase ist eine Open-Source-Firebase-Alternative — ein Backend-as-a-Service, das auf Postgres aufbaut. Es ist eigentlich überhaupt kein CMS. Es ist eine Datenbankplattform mit Auth, Storage, Realtime-Subscriptions und Edge Functions. Aber Teams nutzen es ständig als CMS-Backend, weshalb es in diesen Vergleichen immer wieder auftaucht.

Diese Unterscheidung ist wichtiger als alles andere in diesem Artikel. Directus und Payload sind speziell für Content-Management konzipierte Systeme. Supabase ist ein universeller Backend, den Sie mit genug Effort in ein Content-Management-System umformen können.

Architektur und Datenmodellierung im Vergleich

Directus: Datenbank-zentriert

Directus besitzt Ihr Schema nicht. Sie können es auf eine existierende Datenbank zeigen und es wird automatisch ein Admin-Panel generieren. Das ist wirklich mächtig, wenn Sie mit Legacy-Systemen arbeiten oder wenn Ihr Datenmodell mehrere Anwendungen über das Content-Management hinaus bedient.

Die Relationship-Modellierung in Directus ist solide. M2M, M2O, O2M, und sogar Übersetzungen werden über die UI bearbeitet. Aber es gibt einen Haken: Da Directus die Datenbank introspiziert, anstatt sie aus Code zu generieren, passieren Ihre Schemaänderungen an zwei Orten — in Migrations und im Directus-Admin. Das kann in Team-Umgebungen unordentlich werden, wenn Sie nicht diszipliniert sind.

# Directus-Schema-Snapshot (vereinfacht)
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: Code-zentriert

Payload 3.0 (die aktuelle Version 2026) läuft als Plugin in Next.js. Ihre Collections sind in TypeScript definiert:

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

Dieser Code-zentrierte Ansatz bedeutet, dass Ihr Schema in der Versionskontrolle lebt. Sie bekommen auto-generierte vollständige TypeScript-Typen aus Ihrer Config. Das ist die beste DX der drei für TypeScript-lastige Teams. Der Nachteil? Nicht-Entwickler können das Datenmodell nicht ohne Code-Änderung modifizieren.

Supabase: SQL-zentriert

Mit Supabase schreiben Sie SQL. Rohes Postgres. Sie definieren Ihre Tabellen, richten Row-Level-Security-Policies ein und interagieren dann über die auto-generierte REST-API (PostgREST) oder den JavaScript-Client.

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
);

-- Row Level Security
ALTER TABLE articles ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Public can read published articles"
  ON articles FOR SELECT
  USING (published = true);

Sie bekommen maximale Flexibilität, aber null Content-Management-UI ab Werk. Sie werden entweder ein Custom-Admin bauen, ein Third-Party-Tool nutzen, oder etwas wie Directus auf derselben Postgres-Instanz aufsetzen (ja, Menschen tun das tatsächlich).

Content-Editing-Erfahrung

Hier trifft die CMS-vs-nicht-a-CMS-Unterscheidung am härtesten zu.

Feature Directus Payload Supabase
Built-in Admin-UI ✅ Poliert, anpassbar ✅ Next.js-native, sehr gut ❌ Nur Tabellen-Editor
Rich-Text-Editor ✅ WYSIWYG + Markdown ✅ Lexical-basiert (hervorragend) ❌ Keiner
Medienbibliothek ✅ Vollständig ausgestattet ✅ Vollständig ausgestattet ⚠️ Storage-Buckets (keine Bibliotheks-UI)
Content-Vorschau ✅ Via benutzerdefinierte Module ✅ Native Live-Vorschau ❌ Selbst erstellen
Lokalisierung ✅ Eingebautes Übersetzungssystem ✅ Field-Level-Lokalisierung ❌ Manuelle Implementierung
Content-Versionierung ✅ Revisions eingebaut ✅ Drafts + Versionen ❌ Selbst erstellen
Workflow / Publishing ✅ Flows-System ✅ Draft/Publish-States ❌ Benutzerdefinierte Logik nötig
Nicht-Entwickler-freundlich ✅ Sehr ✅ Ja ❌ Überhaupt nicht

Wenn Ihr Projekt Content-Editoren einbezieht — Menschen, die Blog-Posts schreiben, Produktkataloge verwalten, Landing Pages aktualisieren — ist Supabase das falsche Tool. Punkt. Sie würden Wochen damit verbringen zu bauen, was Directus und Payload am ersten Tag geben.

Die Editor-Erfahrung von Payload ist seit 3.0 bemerkenswert gut geworden. Der Lexical-basierte Rich-Text-Editor ist flexibel, die Live-Preview-Funktion arbeitet wunderbar mit Next.js-Frontends und das Admin-Panel fühlt sich native an, weil es buchstäblich in Ihrer Next.js-App läuft.

Directus hat das reifste Admin-Panel der drei. Es wurde über Jahre verfeinert, und das Custom-Display/Interface-System bedeutet, dass Sie komplexe Editorial-Workflows ohne Frontend-Code bauen können. Für content-lastige Organisationen zählt das sehr.

Directus vs Payload vs Supabase: Which CMS Backend to Use in 2026 - architecture

Developer Experience und API-Design

API-Stile

Directus gibt Ihnen REST und GraphQL ab Werk, plus ein JavaScript-SDK. Die REST-API folgt einem konsistenten Muster, und die GraphQL-Implementierung wird aus Ihrem Schema auto-generiert. Es funktioniert, aber die GraphQL kann sich für komplexe verschachtelte Queries limitiert anfühlen.

Payload generiert REST- und GraphQL-APIs, plus Sie bekommen vollständigen Zugriff auf die Local API (direkte Datenbankqueries ohne HTTP-Overhead). Da Payload 3.0 in Ihrer Next.js-App läuft, können Sie payload.find() direkt in Ihren Server Components aufrufen. Das ist ein massiver Vorteil für Next.js-Projekte.

// Payload Local API in einem Next.js Server Component
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's API wird von PostgREST auto-generiert, und die JavaScript-Client-Bibliothek ist wirklich hervorragend. Der Query-Builder fühlt sich natürlich an:

const { data, error } = await supabase
  .from('articles')
  .select('*, author:authors(*)')
  .eq('published', true)
  .order('created_at', { ascending: false })
  .range(0, 9)

Supabase hat auch Realtime-Subscriptions, die weder Directus noch Payload nativ anbieten. Wenn Sie Live-Daten-Updates brauchen (Chat, Benachrichtigungen, kollaboratives Editing), gewinnt Supabase standardmäßig.

Typ-Sicherheit

Payload hat die beste TypeScript-Story. Types werden aus Ihren Collection-Configs generiert, und alles ist end-to-end stark typisiert. Supabase hat solide Type-Generierung durch ihre CLI (supabase gen types typescript), die Types aus Ihrem Datenbankschema erstellt. Directus hat ein TypeScript-SDK, aber die Type-Generierung erfordert zusätzliche Konfiguration und ist nicht so eng integriert.

Authentifizierung, Berechtigungen und Row-Level Security

Hier glänzt Supabase wirklich. Postgres Row-Level Security (RLS) ist das granularste, am meisten bewährte Berechtigungsmodell der drei. Sie definieren Policies auf Datenbankebene, und sie gelten unabhängig davon, wie auf die Daten zugegriffen wird. Es ist unglaublich mächtig für Multi-Tenant-SaaS-Anwendungen.

Directus hat ein rollenbasiertes Berechtigungssystem, das auf Collection- und Field-Ebene funktioniert. Es ist in der Admin-Panel intuitiv und ausreichend für die meisten CMS-Use-Cases. Sie können Pro-Rolle CRUD-Berechtigungen setzen und sogar benutzerdefinierte Filter-Regeln hinzufügen.

Payload bietet Field-Level- und Collection-Level-Zugriffskontrolle durch Funktionen in Ihrer Config:

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

Für ein Standard-CMS mit Redakteuren, Reviewern und Admins funktionieren alle drei gut. Für komplexe Multi-Tenant-Anwendungen mit dynamischen Berechtigungsregeln ist Supabase's RLS die mächtigste Option.

Self-Hosting, Cloud und Pricing 2026

Alle drei sind Open Source und self-hostbar. Aber die Cloud-Pricing-Struktur sagt viel über ihre Zielmärkte aus.

Plan Directus Cloud Payload Cloud Supabase Cloud
Kostenlos-Tier ❌ Keine kostenlose Cloud ✅ 1 Projekt, limitiert ✅ 2 Projekte, 500MB DB
Starter/Pro $99/mo (Professional) $35/mo (Standard) $25/mo (Pro)
Team/Business $399/mo (Enterprise) Custom Pricing $599/mo (Team)
Self-hosted Kosten Kostenlos (Open Source) Kostenlos (Open Source) Kostenlos (Open Source)
Datenbank enthalten ✅ Verwaltet ✅ Verwaltetes Postgres ✅ Verwaltetes Postgres
CDN/Storage Enthalten Enthalten Enthalten mit Limits

Pricing Stand Q1 2026. Prüfen Sie die Pricing-Seiten jeder Plattform für aktuelle Tarife.

Payload Cloud ist die günstigste verwaltete Option für kleine bis mittlere Projekte. Supabase's kostenlos-Tier ist am großzügigsten zum Prototyping und für Side-Projects. Directus Cloud zielt auf größere Organisationen ab, die für ein poliertes verwaltetes Erlebnis zahlen.

Self-Hosting ändert die Gleichung dramatisch. Alle drei laufen gut auf einem $5-20/Monat-VPS. Directus und Supabase haben offizielle Docker-Compose-Setups, die zuverlässig funktionieren. Payload deployt überall dort, wo Next.js läuft — Vercel, Railway, Fly.io, Ihr eigener Server.

Für unsere Headless-CMS-Development-Projekte empfehlen wir üblicherweise Self-Hosting auf Railway oder Fly.io für Kosteneffizienz, mit verwalteter Cloud nur, wenn der Client garantierte SLAs braucht.

Performance- und Scalability-Benchmarks

Ich habe einige informelle Benchmarks auf äquivalenter Hardware durchgeführt (4 vCPU, 8GB RAM, Postgres 16) mit einem Datensatz von ~50.000 Content-Records.

Operation Directus Payload Supabase
Einfache List-Query (20 Items) ~45ms ~12ms (Local API) / ~38ms (REST) ~18ms
Verschachtelte Relationship-Query (Tiefe 3) ~120ms ~35ms (Local API) / ~95ms (REST) ~55ms
Volltext-Suche (1000 Ergebnisse) ~180ms ~85ms ~40ms (pg_trgm)
Bulk-Insert (1000 Records) ~2.1s ~1.8s ~0.9s
Cold-Start-Zeit ~3.5s ~2.8s N/A (läuft immer)

Payload's Local API ist die schnellste Option für Next.js-Anwendungen, da es keinen HTTP-Overhead gibt — Sie fragen die Datenbank direkt aus Ihrem Rendering-Prozess ab. Supabase's rohes Postgres-Performance ist für datenintensive Operationen schwer zu schlagen. Directus fügt durch die Abstraktionsschicht etwas Overhead hinzu, ist aber für Content-Serving-Workloads völlig in Ordnung.

Bei der Suche hat Supabase einen signifikanten Vorteil, da Sie Postgres's native Volltext-Suche, Trigram-Indizes und sogar die pgvector-Extension für semantische Suche nutzen können. Directus und Payload unterstützen beide Suche, verlassen sich aber auf ihre eigenen Implementierungen, anstatt Postgres direkt zu nutzen.

Das Decision-Framework: Wann welches Tool nutzen

Hier ist das tatsächliche Framework. Beantworten Sie diese Fragen, und Ihre Wahl wird offensichtlich.

Wählen Sie Directus wenn:

  • Ihr Content-Team groß und nicht-technisch ist
  • Sie eine existierende Datenbank mit einer CMS-Schicht umhüllen müssen
  • Sie eine andere Datenbank als Postgres nutzen (MySQL, MS SQL, etc.)
  • Sie ein Standalone-CMS brauchen, das mehrere Frontends bedient (Web, Mobile, Kiosk)
  • Ihr Frontend ist nicht Next.js (vielleicht Astro, Nuxt oder SvelteKit)
  • Sie wollen maximale Flexibilität in Admin-UI-Anpassung ohne Code

Directus passt wunderbar zu Astro für content-lastige Sites, wo Build-Zeit-Rendering und Island Architecture mehr Sinn machen als ein vollständiges React-Framework.

Wählen Sie Payload wenn:

  • Ihr Frontend ist Next.js (das ist der Killer-Use-Case)
  • Ihr Team ist TypeScript-First und will Typ-Sicherheit überall
  • Sie CMS und Frontend in einer einzigen deployable Unit wollen
  • Sie Live-Preview und visuelle Editing-Fähigkeiten brauchen
  • Sie Code-definierte Schemas in der Versionskontrolle wollen
  • Sie eine Site bauen, wo das Content-Modell von vornherein gut-definiert ist

Payload ist unsere Standard-Empfehlung für Next.js-Development-Projekte, wo Content-Management eine Kernforderung ist. Die Integration ist unvergleichlich.

Wählen Sie Supabase wenn:

  • Sie ein Anwendung bauen, nicht eine Content-Website
  • Sie Realtime-Features brauchen (Chat, Live-Updates, Zusammenarbeit)
  • Sie komplexe Multi-Tenant-Berechtigungen brauchen (RLS ist König)
  • Ihr Hauptbedarf ist ein Backend, und Content ist sekundär
  • Sie Postgres-Extensions nutzen wollen (pgvector, PostGIS, pg_cron)
  • Ihr Team sich wohlfühlt, ihre eigenen Admin-Interfaces zu bauen
  • Sie ein SaaS-Produkt bauen, wo nutzer-generierte Daten wichtiger sind als Editorial-Content

Real-World-Projekt-Szenarien

Szenario 1: Marketing-Website mit Blog

Beste Wahl: Payload (wenn Next.js) oder Directus (wenn Astro/sonstiges)

Eine Marketing-Site mit 50-200 Seiten, einem Blog und einem kleinen Content-Team von 2-3 Personen. Sie brauchen Landing-Page-Flexibilität, Bild-Optimierung, SEO-Metadaten-Verwaltung und vielleicht etwas A/B-Testing.

Payload's Live-Preview-Feature ist perfekt hier. Content-Editoren können genau sehen, wie die Seite aussehen wird, bevor sie veröffentlicht wird. Der Block-basierte Field-Type lässt Sie flexible Landing Pages bauen, ohne Editoren genug Seil zum Erhängen geben.

Szenario 2: E-Commerce-Produktkatalog

Beste Wahl: Directus oder Payload

Ein Produktkatalog mit 5.000+ SKUs, komplexer Kategorisierung, mehreren Preislisten und Integration mit Bestandssystemen. Der Schlüssel hier ist Datenmodell-Flexibilität und die Fähigkeit, strukturierte Daten effizient zu handhaben.

Directus hat einen Vorteil, wenn Sie eine existierende Produktdatenbank verbinden müssen, ohne Daten zu migrieren. Payload gewinnt, wenn Sie von null anfangen und typ-sichere Produktqueries in Ihrem Next.js-Storefront wollen.

Szenario 3: Multi-Tenant-SaaS-Plattform

Beste Wahl: Supabase

Eine Plattform, wo jeder Kunde seinen eigenen Datenraum hat, mit rollenbasiertem Zugriff, Realtime-Benachrichtigungen und nutzer-generiertem Content. Sie brauchen Row-Level Security, Edge Functions für Business-Logik und die Fähigkeit, horizontal zu skalieren.

Das ist kein CMS-Projekt — es ist ein Application-Backend-Projekt. Supabase wurde genau dafür gebaut.

Szenario 4: Interne Knowledge Base

Beste Wahl: Payload oder Directus

Eine interne Wiki/Knowledge Base für ein 200-Personen-Unternehmen. Rich-Text-Content, Kategorisierung, Suche und rollenbasierter Zugriff. Content-Editoren reichen von technisch bis nicht-technisch.

Beide CMSs funktionieren gut hier. Directus hat einen leichten Vorteil für nicht-technische Teams, da das Admin-Panel zero Code zum Anpassen braucht. Payload ist besser, wenn Sie ein poliertes, branded Frontend-Erlebnis wollen.

Migrationspfade und Lock-In-Überlegungen

Lock-In ist real. Denken Sie daran, bevor Sie sich festlegen.

Directus hat das wenigste Lock-In, da Ihr Datenbankschema unabhängig vom CMS ist. Entfernen Sie Directus und Sie haben immer noch eine saubere, standard SQL-Datenbank. Ihre Daten sind nicht in einem proprietären Format gefangen.

Payload speichert Daten in Standard-Postgres (oder MongoDB) Tabellen, aber das Schema folgt Payload's Konventionen. Weg zu migrieren bedeutet, ein paar Dinge umzustrukturieren, aber Ihre Daten sind immer noch in einer Standard-Datenbank.

Supabase ist nur Postgres. Null Lock-In. Sie können ein Datenbankdump nehmen und es auf jeder Postgres-Instanz laufen lassen. Die Client-Bibliothek ist nur ein Wrapper um PostgREST und GoTrue. Wenn Supabase morgen verschwinden würde, müssten Sie einige API-Aufrufe ersetzen, aber Ihre Daten und Ihr Schema würden perfekt intakt sein.

Alle drei sind beim Lock-In deutlich besser als proprietäre CMS-Plattformen wie Contentful oder Sanity, wo Ihre Daten in der Cloud von jemand anderem lebt und der Export davon ist immer ein Partial-Prozess.

FAQ

Kann ich Supabase als Headless-CMS nutzen?

Technisch ja, aber Sie werden CMS-Features von Grund auf bauen — Content-Editing-UI, Medienverwaltung, Revisions-Historie, Publishing-Workflows. Für kleine Projekte mit nur-Entwickler-Content-Management könnte es funktionieren. Für alles, das nicht-technische Editoren einbezieht, nutzen Sie ein echtes CMS wie Payload oder Directus und verbinden Sie Supabase für Application-Daten, wenn nötig.

Ist Payload wirklich kostenlos? Was ist der Haken?

Payload CMS ist wirklich Open Source unter der MIT-Lizenz. Sie können es für immer kostenlos selbst-hosten. Payload Cloud ist ihr bezahlter verwalteter Hosting-Service, startet bei $35/Monat. Der Haken, wenn Sie ihn so nennen wollen, ist, dass Payload Cloud einige Premium-Features wie Form-Builder und SEO-Plugins hat, die kostenlos sind, aber von der gehosteten Umgebung profitieren. Das Kern-CMS ist vollständig funktional ohne etwas zu zahlen.

Kann ich Directus und Supabase zusammen nutzen?

Absolut, und das ist ein Muster, das ich mehrfach genutzt habe. Zeigen Sie Directus auf eine Supabase-Postgres-Datenbank. Sie bekommen Directus's Admin-Panel für Content-Management und Supabase's Realtime-Subscriptions, Auth und Edge Functions für Application-Features. Die zwei Tools ergänzen sich wunderbar, da sie auf verschiedenen Schichten operieren.

Was ist das Beste für ein Next.js-Projekt?

Payload, und es ist nicht einmal knapp. Da Payload 3.0 das CMS als Plugin in der Next.js-Anwendung läuft. Sie bekommen die Local API für overhead-freie Datenbankqueries in Server Components, native Live-Preview und ein einziger Deployment. Wir nutzen diese Kombination konstant in unserer Next.js-Entwicklungsarbeit.

Wie vergleichen sich diese mit Strapi 2026?

Strapi v5 ist eine solide Option, hat aber in ein paar Bereichen nachgelassen. Das Admin-Panel wirkt veraltet im Vergleich zu Payload's, die TypeScript-Unterstützung ist nicht so stark und das Lizenzmodell ist restriktiver geworden. Directus bietet einen ähnlichen datenbankumhüllenden Ansatz mit einer modernerem UI. Payload bietet bessere DX für TypeScript-Teams. Strapi's Hauptvorteil ist das größere Plugin-Ökosystem und die größere Community, aber der Abstand schließt sich.

Was ist mit Sanity, Contentful oder anderen SaaS-CMS-Plattformen?

Sanity und Contentful sind großartige Produkte, aber sie sind proprietäre SaaS-Plattformen. Ihre Daten leben auf ihren Servern, Pricing skaliert mit Usage (und kann schnell teuer werden) und Sie sind von ihrer Infrastruktur abhängig. Directus, Payload und Supabase sind alle Open Source und self-hostbar. Wenn Dateneigentum, Kostenkontrolle und Deployment-Flexibilität für Sie wichtig sind, gewinnen die Open-Source-Optionen. Wir behandeln das mehr im Detail auf unserer Headless-CMS-Development-Seite.

Welches hat das beste Plugin/Extension-Ökosystem?

Directus hat einen Marketplace mit Community-Extensions für Custom-Interfaces, Displays und Module. Payload hat ein wachsendes Plugin-Ökosystem mit offiziellen Plugins für SEO, Formulare, Nested Docs und Redirects. Supabase hat Postgres-Extensions (hunderte davon), die einen anderen Zweck erfüllen, aber unglaublich mächtig sind. Für CMS-spezifische Plugins hat Directus derzeit die meisten Optionen.

Was ist die beste Option für ein kleines Team mit kleinerem Budget?

Payload self-hosted auf Vercel's kostenlos-Tier oder Railway's Hobby-Plan. Sie bekommen ein vollständiges CMS mit null monatliche Kosten für Low-Traffic-Projekte. Supabase's kostenlos-Tier ist auch hervorragend zum Prototyping. Directus erfordert Self-Hosting um kostenlos zu sein (kein kostenlos Cloud-Tier), läuft aber gut auf einem $5/Monat-VPS. Wenn Budget knapp ist und Sie Hilfe brauchen, die richtige Wahl zu treffen, kontaktieren Sie uns — wir haben vielen Teams geholfen, die kosteneffektivste Architektur zu finden.