Payload gegen Strapi, Storyblok und Sanity 2026

Die nüchterne Beobachtung zuerst: Payload sieht in technischen Demos größer aus, als es im Markt ist. W3Techs weist Payload CMS im September 2026 mit 0,1 % Marktanteil unter bekannten CMS-Websites aus. Gleichzeitig laufen laut derselben W3Techs-Seite 79,6 % der beobachteten Payload-Websites bereits auf Version 6, während 20,4 % noch Version 3 nutzen. Das ist ein ungewöhnlich klares Signal. Die installierte Basis ist klein, aber der aktive Teil zieht schnell mit.

Strapi hat eine andere Kurve. Ideaproof nennt rund 73.000 GitHub-Stars für Strapi und rund 44.000 für Payload. GitHub-Stars sind kein Architekturargument, aber sie sind ein brauchbarer Proxy für Suchbarkeit, Stack-Overflow-Spuren, fertige Integrationen und die Wahrscheinlichkeit, dass ein neuer Entwickler das Tool schon gesehen hat. Technology Checker meldet für Strapi seit März 2026 eine positive Nettobewegung mit 53 gewonnenen und 17 verlorenen Domains sowie 2.847 Domains im monatlichen Crawl. Das ist kein Beweis für Qualität, aber es zeigt Traktion im produktiven Web.

Storyblok spielt anders. DXP Scorecard nennt für Juni 2026 mehr als 2,4 Millionen monatliche npm-Downloads für die drei wichtigsten Storyblok-Pakete. Store Leads meldet 2.424 E-Commerce-Stores mit Storyblok und +21,6 % Wachstum gegenüber dem Vorjahr. Diese Zahl ist besonders relevant für Händler, Agenturen und Hersteller mit Content-getriebenen Produktseiten, weil Storyblok dort weniger als Datenbank-Admin und mehr als Arbeitsoberfläche für Marketing funktioniert.

Sanity ist in diesem Vergleich der Sonderfall. Ohne gleichwertige Zahlen aus dem Recherchematerial bleibt die Einordnung qualitativer: Sanity ist stark, wenn strukturierte Inhalte über mehrere Kanäle modelliert werden und Content-Teams mit Entwicklern an einem gemeinsamen Schema arbeiten. Der Punkt im Vergleich Payload CMS vs Strapi, Storyblok vs Sanity ist damit nicht, wer überall gewinnt. Der Punkt ist, dass Marktgröße und technischer Fit 2026 auseinanderlaufen.

“

Payload sieht in technischen Demos größer aus, als es im Markt ist.

Payload und Strapi sind für Teams interessant, die ihr CMS nicht als fremde Blackbox behandeln wollen. Beide sind Open Source und self-hostbar. Payload ist stärker auf TypeScript und Code-first-Konfiguration ausgerichtet. Strapi wirkt klassischer: Admin-Panel, Plugins, Content-Types, viel vorhandenes Material. Für ein Team, das mit Node.js umgehen kann, ist beides handhabbar. Der Unterschied zeigt sich weniger beim ersten Blogpost als bei der dritten Ausnahme im Datenmodell.

Payload passt gut, wenn das CMS Teil der Produktarchitektur ist. Custom Collections, Zugriffskontrolle, Hooks und Typen leben nah am Code. Das reduziert Reibung, wenn du ein SaaS-Produkt baust, in dem Content, Accounts, Rollen und interne Workflows nicht sauber voneinander getrennt sind. Strapi ist angenehmer, wenn du schnell viele bekannte CMS-Funktionen brauchst und nicht jede Integration selbst bauen willst. Das größere Plugin-Ökosystem ist dort ein echtes Argument.

Storyblok und Sanity verschieben den Schwerpunkt. Storyblok liefert einen visuellen Editor, der für Marketing-Teams oft wichtiger ist als die Eleganz des Schemas. Sanity setzt auf ein eigenes Content Studio und GROQ als Abfragesprache. Das ist mächtig, aber es bringt eine zusätzliche Denkschicht. Für Senior-Teams ist das kein Problem. Für ein kleines Produktteam ohne klare Ownership für Content-Architektur wird es schnell zu viel Werkzeug für zu wenig Prozess.

Im österreichischen Kontext ist Self-Hosting kein ideologisches Hobby. Wenn ein Wiener B2B-SaaS im weXelerate Kundendaten, Rollenmodelle und redaktionelle Freigaben in einem CMS abbildet, sitzen Datenschutzbehörde, Auftragsverarbeiterlisten und technische TOMs gedanklich mit am Tisch. SaaS-only kann absolut vertretbar sein, aber es muss vertraglich und organisatorisch sauber geklärt werden. Ein Self-Hosting CMS Österreich-Setup mit Payload oder Strapi ist oft langweiliger, aber leichter erklärbar.

“

Im österreichischen Kontext ist Self-Hosting kein ideologisches Hobby.

import { buildConfig } from 'payload'
import { postgresAdapter } from '@payloadcms/db-postgres'
import { lexicalEditor } from '@payloadcms/richtext-lexical'

export default buildConfig({
  secret: process.env.PAYLOAD_SECRET || 'dev-secret-change-me',
  editor: lexicalEditor(),
  db: postgresAdapter({
    pool: {
      connectionString: process.env.DATABASE_URI || 'postgres://postgres:postgres@localhost:5432/payload'
    }
  }),
  collections: [
    {
      slug: 'posts',
      admin: {
        useAsTitle: 'title'
      },
      fields: [
        {
          name: 'title',
          type: 'text',
          required: true
        },
        {
          name: 'slug',
          type: 'text',
          required: true,
          unique: true
        },
        {
          name: 'body',
          type: 'richText'
        }
      ]
    }
  ]
})

Der Headless CMS Kosten Vergleich wird oft falsch geführt. Lizenzpreis ist nur eine Zeile. Die relevanteren Zeilen heißen Betrieb, Updates, Editor-Schulung, Migrationsrisiko, Preview-Infrastruktur, Rollenmodell, Suche, Bildverarbeitung, Backups und Support. SaaS-Anbieter verpacken viele dieser Punkte in ein Paket. Open-Source-Systeme geben dir die Rechnung nicht weg, sondern verschieben sie in dein Team.

Payload und Strapi starten ohne Lizenzkosten, wenn du sie selbst betreibst. Das ist attraktiv, aber nicht gratis. Du brauchst Hosting, Datenbank, Storage, Monitoring, Backups, Deployments und jemanden, der Security-Updates nicht als Kalenderdeko behandelt. Für ein hypothetisches kleines Team in Linz kann ein Open-Source-Setup mit einem Managed-Postgres, Objekt-Storage und einfacher Observability günstiger sein als ein SaaS-Plan mit steigenden API-Limits. Für ein hypothetisches Medienprojekt mit stark schwankendem Traffic kann SaaS dagegen billiger sein, weil Caching, CDN und Redaktionsfunktionen weniger Eigenbau brauchen.

Storyblok verkauft vor allem Zeit für Marketing-Teams. Wenn Redakteure Landingpages ohne Entwickler anfassen müssen, ist ein Visual Editor kein Luxus. Er ist Kostenvermeidung. Sanity verkauft Modellierungsfreiheit und Kollaboration. Das lohnt sich, wenn Content als strukturierter Produktbestandteil behandelt wird, nicht nur als Blog. Beide Systeme können bei Traffic, Seats, Workspaces oder erweiterten Funktionen preislich spürbar steigen. Ohne aktuelle Anbieter-Preislisten sollte man hier keine exakten Monatsbeträge als Wahrheit verkaufen.

Der sichere Freelancer-Rat lautet oft: Nimm Strapi, weil es bekannter ist. Für TypeScript-lastige Produktteams halte ich das 2026 für zu konservativ. Payload ist trotz kleinem Marktanteil die bessere Startwahl, wenn das CMS mit Geschäftslogik verwoben ist und nicht bloß Seiten ausliefert. Das größere Ökosystem von Strapi hilft bei Standardfällen. Es hilft weniger, wenn dein Kernproblem ein eigenes Datenmodell mit klaren Typen, Hooks und Zugriffskontrolle ist.

“

Open-Source-Systeme geben dir die Rechnung nicht weg, sondern verschieben sie in dein Team.

Langfristige CMS-Entscheidungen scheitern selten an der Demo. Sie scheitern an Version-Upgrades, verlassenen Plugins, fehlenden Integrationen und internen Workarounds. Deshalb sind Entwicklungsaktivität und Ökosystem keine Vanity-Metriken. Ideaproof zählt für Payload in den letzten 12 Monaten 1.777 Commits, Aktivität in 12 von 12 Monaten und ein letztes Release im August 2026. Für Strapi nennt Ideaproof 1.407 Commits im selben Zeitraum, ebenfalls mit Aktivität in allen 12 Monaten. Beide Projekte wirken also lebendig, nur mit unterschiedlicher Marktbreite.

Die Aktivität von Payload ist bemerkenswert, weil sie nicht durch eine riesige installierte Basis erklärt wird. Das Projekt bewegt sich schnell. Das ist gut, wenn du moderne TypeScript-Patterns willst. Es ist weniger gut, wenn dein Unternehmen Änderungen als Risiko behandelt und nur alle paar Quartale größere Upgrades anfassen will. Ein schnelles Projekt produziert Fortschritt und Migrationsarbeit gleichzeitig.

Strapi ist berechenbarer im Recruiting-Sinn. Du findest eher jemanden, der Strapi schon produktiv gesehen hat. Du findest mehr Blogposts, mehr Plugin-Diskussionen, mehr Stack-Spuren. Dafür trägst du bei komplexeren Produktanforderungen häufiger Altlasten aus einer Admin-zentrierten Denkweise mit. Das ist kein KO-Kriterium, aber es prägt Architekturentscheidungen.

Storyblok und Sanity haben ein anderes Risikoprofil. Du kaufst Plattformbetrieb und Produktfeatures ein, aber du bindest dich stärker an APIs, Editor-Konzepte und Preismodelle. Bei Storyblok ist das Risiko für Marketing-Websites oft akzeptabel, weil der visuelle Editor den Alltag verbessert. Bei Sanity ist die Bindung technischer, weil GROQ, Studio-Konfiguration und Content Lake tief in die Anwendung rutschen können. Vendor-Lock-in ist nicht automatisch schlecht. Schlechter ist ein Team, das Lock-in eingeht und so tut, als wäre es Portabilität.

const query = `*[_type == "landingPage" && slug.current == $slug][0]{
  title,
  "slug": slug.current,
  sections[]{
    _type,
    heading,
    body,
    ctaLabel,
    "imageUrl": image.asset->url
  }
}`

const params = { slug: 'produkt-demo' }

export { query, params }

Für ein TypeScript CMS mit Produktnähe ist Payload 2026 die stärkste Wahl. Das gilt besonders, wenn du Auth, Rollen, interne Admin-Flows, Webhooks und Content in einem System abbildest. Payload CMS Erfahrungen fallen dann positiv aus, wenn Entwickler Ownership übernehmen und nicht erwarten, dass jedes Problem als fertiges Plugin existiert. Der geringe W3Techs-Marktanteil von 0,1 % bleibt ein reales Risiko, aber kein ausreichender Grund, ein schlechter passendes System zu wählen.

Strapi passt für klassische Content-Sites, interne Portale und Teams, die ein bekanntes Open-Source-CMS mit großer Community suchen. Wenn du viele Standardintegrationen brauchst, ist Strapi oft schneller produktiv. Der Vorsprung bei GitHub-Stars laut Ideaproof, rund 73.000 gegenüber rund 44.000 bei Payload, ist in solchen Projekten praktisch relevant. Es bedeutet mehr Tutorials, mehr Fehlermeldungen mit Suchtreffern und wahrscheinlich weniger Erklärungsaufwand gegenüber neuen Entwicklern.

Storyblok ist die bessere Wahl, wenn Marketing selbst Seiten zusammenstellt und visuelle Kontrolle braucht. Für E-Commerce ist die Store-Leads-Zahl von 2.424 Stores und +21,6 % YoY ein starkes Signal. Das Tool passt zu Teams, die Content-Geschwindigkeit höher bewerten als Datenhoheit. Ein DACH-Händler mit mehreren Kampagnen pro Woche gewinnt durch den Editor mehr als durch ein perfektes Schema im Repository.

Sanity ist richtig, wenn dein Content nicht nur Website-Text ist. Produktdaten, Lokalisierung, Knowledge Base, App-Inhalte und redaktionelle Module können in Sanity sauber modelliert werden. Dafür brauchst du Entwickler, die das Content Studio ernst nehmen und GROQ nicht als nette Abfragesprache nebenbei behandeln.

Bestes Headless CMS für Startups ist daher keine allgemeine Antwort. Für ein frühes SaaS mit starker Engineering-Kultur: Payload. Für ein KMU mit Standardwebsite und knapper Entwicklerzeit: Strapi. Für Marketing-getriebene E-Commerce-Teams: Storyblok. Für mehrkanalige Content-Modelle mit Enterprise-Anspruch: Sanity.

“

Bestes Headless CMS für Startups ist daher keine allgemeine Antwort.