Sanity in 2026: wo es gewinnt und wo Payload es schlägt

Wenn du deine Headless-CMS-Wahl auf Sanity gegenüber der Payload-oder-Storyblok-Fraktion eingegrenzt hast, hast du bereits 80 Prozent des Lärms eliminiert, den der Rest dieser Kategorie ausstößt. Die verbleibende Entscheidung ist die interessante: Optimierst du für das Editorial-Team-Erlebnis oder für das Engineering-Team-Ownership? Wenn du diese Frage richtig beantwortest, ist der Rest der Wahl zumeist erzwungen.

Sanity ist die Antwort, wenn das Editorial-Team die Hauptfigur ist. Nach dem Ausführen von über 12.000 Client-Builds bei Seahawk Media und dem direkten Ausliefern einer Handvoll auf Sanity in den letzten 18 Monaten, hier ist die ehrliche Einschätzung zu wo es gewinnt, wo Payload es schlägt und wo Storyblok es tut. Preisgestaltung, Funktionalität, Migrationspfad und die Trade-offs, die dir niemand auf den Vendor-Sales-Seiten sagen wird.

Was Sanity 2026 wirklich ist

Sanity ist ein gehostetes Headless CMS, in dem du das Schema in TypeScript oder JavaScript schreibst, eine anpassbare React-basierte Admin-App namens Sanity Studio (normalerweise auf deiner eigenen Domain bereitgestellt) betreibst und den Inhalt über GROQ abfragst – eine Graph-ähnliche Abfragesprache, die GraphQL ähnelt, aber bei Dokumentbeziehungen ausdrucksstarker ist. Inhalte sind out-of-the-box in Echtzeit über Redakteure hinweg: zwei Redakteure im selben Dokument sehen die Cursorpositionen des anderen live, wie in Figma.

Die Plattform ist ausgereift: Sanity v3 ist seit zwei Jahren die stabile Major-Version, das Studio ist bis hin zu einzelnen Input-Komponenten genuinely anpassbar, und die Live Content API streamt Document-Änderungen an dein Front End ohne Polling. Sanity ist eine der wenigen Headless-CMS-Optionen in 2026, die sich nicht wie ein Early-Stage-Produkt an einem Dienstagnachmittag anfühlen.

Sanity-Preisgestaltung 2026, die echte Kostenkurve

Drei Pläne. Der kostenlose Plan wirkt großzügig, bis Sie auf die harten Limits stoßen; der Growth-Plan startet bei $15 pro Benutzer pro Monat; Enterprise ist maßgeschneidert und beginnt dort, wo der Growth-Plan nicht mehr skaliert.

Kostenloser Plan

$0/Monat, 20 enthaltene Benutzer ohne Überschussgebühren.
Begrenzt auf Administrator- und Viewer-Rollen, keine Editor-, Developer- oder Contributor-Rollen.
Harte Limits für Dokumente, Assets, API-Anfragen, CDN-Bandbreite. Wenn Sie ein Kontingent erreichen, wird die betroffene Funktionalität blockiert, bis sich das Kontingent zurückgesetzt hat oder Sie upgraden.
Realistisch für: Prototypen, interne Tools oder Content-Websites mit unter 5.000 Dokumenten und einem kleinen Redaktionsteam.

Growth-Plan

$15 pro Benutzer pro Monat, bis zu 50 Benutzer.
Alle fünf Rollen freigeschaltet: Admin, Viewer, Editor, Developer, Contributor.
250.000 API-Anfragen pro Monat inbegriffen, 1 Million API-CDN-Anfragen, danach Pay-as-you-go.
Hard Cap von 25.000 Dokumenten, kein Pay-as-you-go darüber hinaus bei Growth, du musst zu Enterprise wechseln.
Geplante Entwürfe, Kollaborationsfunktionen, Single-Sign-On, wenn Sie das SSO-Add-on hinzufügen (mehr dazu weiter unten).
Realistisch für: die meisten produktiven Content-Seiten mit 1 bis 10 Editoren und unter 25.000 Dokumenten.

Enterprise-Plan

Individuelle Preisgestaltung, Sales-verwaltet.
Höhere Dokumentenlimits, benutzerdefinierte Aufbewahrung, erweiterte Sicherheit, dedizierter Support, SLA-gestützte Performance.
Realistisch für: Seiten mit 50.000+ Dokumenten, regulierte Branchen, Unternehmen mit Beschaffungsanforderungen.

Das SSO-Add-on, das Growth teurer macht, als es aussieht

SAML SSO im Growth-Plan ist ein Add-on für 1.399 USD pro Monat. Für ein 5-köpfiges Team, das sonst 75 USD pro Monat zahlt, multipliziert das Hinzufügen von SSO die Kosten um das 19-fache. Wenn Ihre Sicherheitsrichtlinie SSO vom ersten Tag an verlangt, ist der Growth-Plan ein falsches Sparmodell und Sie zahlen effektiv Enterprise-Preise ohne Enterprise-Funktionsumfang. Das sollte man vor dem Commitment wissen.

Wo Sanity gewinnt (und welche Briefs es wählen)

Echtzeit-Redaktion über verteilte Teams hinweg

Sanitys Kollaborationsmodell ist das nächste, was es in headless CMS dem Arbeiten in einem Google Doc gleichkommt. Zwei Redakteure im selben Dokument sehen die Cursor des anderen. Kommentare werden in einzelnen Feldern gefädelt. Die Dokumentpräsenz ist in der Navigation sichtbar. Für Brand-Teams, Content-Marketing-Teams und alle, bei denen zwei oder mehr Personen regelmäßig im selben Dokument in derselben Stunde arbeiten, ist dies wirklich ein kategorieprägendes Feature.

Schema-Anpassung, die sich nicht wie eine CMS-Vorlage anfühlt

Das Studio ist eine React-App, die du auslieferst. Custom-Input-Komponenten, Custom-Previews, Custom-Workflow-Buttons, Custom-Validierung, Custom-Asset-Pipelines – alles läuft in deinem Repo. Wenn dein Editorial-Team spezifische Anforderungen hat (ein Custom-Datum-und-Zeitzone-Picker, der Bankfeiertage ablehnt, ein Slug-Feld, das gegen eine Konkurrentenliste validiert, eine Custom-Image-Crop-UI), ist Sanity Studio das einzige Headless CMS, in dem du das bauen kannst, ohne gegen die Plattform zu kämpfen.

GROQ als Query-Sprache

GROQ ist ausdrucksstarker als GraphQL für Document-Graph-Abfragen. Du kannst über Referenzen hinweg joinen, verschachtelte Felder projizieren, auf berechnete Werte filtern und Listen in einer einzigen Abfrage slicen. Der Kompromiss ist, dass GROQ Sanity-spezifisch ist – du kannst deine Abfragen nicht woanders hinbringen. Für Teams, die komplexe Content-Oberflächen ausliefern (facettierte Verzeichnisse, Related-Content-Widgets, Multi-Locale-Fallback-Ketten), ist GROQ schneller zu schreiben und schneller zu iterieren als die äquivalente GraphQL-Abfrage plus Frontend-Logik.

Visual Editing auf Next.js Front Ends

Sanitys Visual Editing Feature, seit 2025 allgemein verfügbar, ermöglicht es Redakteuren, direkt auf einer Next.js oder Nuxt Seite im Preview-Modus zu klicken und das zugrundeliegende Feld im Studio zu bearbeiten. Es ist die sauberste Visual-Editing-Geschichte im headless CMS Raum außerhalb von Storyblok. Wenn dein redaktioneller Workflow überwiegend Preview-First ist, ist dies ein echter Produktivitätsgewinn.

Wo Payload Sanity schlägt

Payload ist die richtige Wahl, wenn das Engineering-Team die Hauptrolle beim Build spielt und das Editor-Team in eine etwas stärker entwickler-orientierte Admin-Oberfläche eingearbeitet werden kann.

TypeScript-First-Schemas als kanonische Quelle

Payload-Schemas leben in deinen TypeScript-Dateien neben deinem Anwendungscode. Type Safety ist End-to-End: das Schema, der API-Client und deine Next.js-App teilen sich dieselben Typen ohne Code-Generierungsschritte. Sanitys Schema ist ebenfalls Code-definiert, aber der Type-Generierungsfluss ist aufwendiger und die TypeScript-Story ist weniger nativ.

Self-Hosted, deine Postgres-Datenbank, dein S3-Bucket

Payload ist die bessere Antwort, wenn Dateneigentum nicht verhandelbar ist. Das CMS läuft auf deiner Infrastruktur, die Datenbank ist deine Postgres- oder MongoDB-Instanz, die Assets sitzen in deinem S3-(oder kompatiblen) Bucket. Sanity speichert Dokumente auf Sanitys gehosteter Infrastruktur – für die meisten Teams in Ordnung, ein K.O.-Kriterium für regulierte Branchen oder jedes Team mit einer „kein Third-Party-Datenspeicher"-Politik.

Local API ohne HTTP-Overhead

Sanitys Local API ermöglicht es dir, CMS-Funktionen direkt aus deinem Next.js-Code aufzurufen, ohne einen HTTP-Request zu senden. Für eng integrierte Apps, bei denen das CMS nur eine von mehreren Datenquellen ist, performed das messbar besser als Sanitys Netzwerk-Only-Zugriffsmuster.

Ich habe die Payload-versus-Strapi-Entscheidung ausführlich hier behandelt: Payload vs Strapi in 2026. Die Kurzversion hat die gleiche Form: Payload für TypeScript-lastige Teams, die Ownership wollen, Strapi für Teams, die ein reicheres Plugin-Ökosystem möchten.

Wo Storyblok Sanity schlägt (ein spezifischer Fall)

Storyblok schlägt Sanity auf einer einzigen Dimension und nur einer: dem Visual Editor für Marketing-Teams, die Seiten Komponente-für-Komponente gestalten wollen, ohne Code anzufassen. Storybloks Visual Editor ermöglicht es einem nicht-technischen Marketing-Manager, einen Hero, Hero-with-CTA, Three-Column-Feature-Grid-Layout aus vordefinierten Komponenten-Blöcken zu bauen und die Live-Vorschau dabei zu sehen. Sanitys Visual Editing ist gut, aber es ist nicht um dieselbe Person herum designt.

Wenn Dein Editorial-Team von Marketing-First-Nutzern ohne technischen Hintergrund dominiert wird, die Seiten zusammenstellen möchten, ist Storyblok die richtige Wahl. Wenn Dein Editorial-Team Content-First arbeitet (Schreiber, Redakteure, Journalisten, Knowledge Manager), ist Sanitys Document-First-Editor die bessere Experience.

Migration zu Sanity: der realistische Weg

Aus WordPress

Standardmuster: WordPress-Inhalte über WP All Export exportieren, in das NDJSON-Dokumentformat von Sanity transformieren, über die Sanity CLI importieren. Die Schema-Zuordnung ist die Arbeit – Pages, Posts, Custom Post Types, ACF-Felder benötigen alle ein Sanity-Äquivalent. Das WordPress-zu-Next.js-Migrations-Playbook deckt die SEO-Transport-Seite ab, die unabhängig vom CMS-Ziel relevant ist. Zeit auf einer 5.000-Seiten-Website: 4 bis 8 Wochen konzentrierte Arbeit nur für die Migration, länger, wenn das Schema komplexe relationale Inhalte enthält.

Aus Contentful

Einfacher als WordPress, weil Contentfuls Content-Modell sich sauber auf Sanitys Document-and-Reference-Struktur abbildet. Die Sanity-Migrations-Tools haben dedizierte Importer für Contentful-Exports. Realistischer Zeitrahmen bei einer ähnlich großen Website: 2 bis 4 Wochen.

Aus Drupal

Das schwierigste der drei, weil Drupals Entity-and-Bundle-Modell strukturell unterschiedlich ist. Die meisten Teams bauen das Schema in Sanity von Grund auf neu auf, anstatt automatisch zu migrieren. 6 bis 12 Wochen für eine komplexe mehrsprachige Drupal-Website.

FAQ

Ist Sanity HIPAA-konform?

Sanity veröffentlicht in seinem Growth-Plan keine HIPAA Business Associate Agreement, daher ist Sanity standardmäßig nicht HIPAA-berechtigt zur Speicherung von PHI. Enterprise-Kunden mit Healthcare-Workflows können eine benutzerdefinierte Datenschutzvereinbarung verhandeln, aber das ist nicht die Voreinstellung. Wenn deine Healthcare-App ein CMS benötigt, das PHI direkt speichert, ist Supabase mit dem HIPAA Add-on oder eine selbst gehostete Payload-Bereitstellung auf einem HIPAA-berechtigten Host ein defensiblerer Weg.

Ist Sanity besser als Contentful?

Für die meisten Teams im Jahr 2026 – ja, Sanity bietet mehr Schema-Flexibilität, bessere Echtzeit-Zusammenarbeit, eine leistungsfähigere Abfragesprache (GROQ) und einen deutlich niedrigeren Preis für gleichwertige Feature-Sets. Contentfuls Stärke ist Enterprise-Beschaffung und Integrationen mit Legacy-Marketing-Stacks. Wenn dein Team technisch ist und der Editorial-Workflow die Priorität ist, ist Sanity die bessere Wahl. Wenn deine Stakeholder einen beschaffungsfreundlichen Enterprise-Vertrag verlangen, ist Contentful die sicherere Wahl.

Wie viel kostet Sanity für ein 5er-Team?

Im Growth-Plan $75 pro Monat für 5 Seats à $15 pro Seat. Wenn du SAML SSO brauchst, addiere $1.399 pro Monat, was die gleiche Mannschaft auf $1.474 monatlich bringt. Der kostenlose Plan deckt 20 Seats mit Hard Caps ab, also falls dein Team klein ist und deine Nutzung niedrig, kann die kostenlose Stufe dich das erste Jahr tragen.

Kann ich Sanity mit Next.js verwenden?

Ja, Next.js ist 2026 das häufigste Frontend für Sanity. Das offizielle @sanity/client-Paket handhabt die API-Aufrufe, GROQ-Abfragen laufen serverseitig in Server Components oder via API Routes, und Visual Editing wird im Preview-Modus unterstützt. Sanity hat eine gepflegte Next.js-Starter-Template; sie zu klonen ist der schnellste Weg zu einem funktionierenden Projekt.

Was ist GROQ und warum ist es wichtig?

GROQ ist Sanitys Content-Query-Sprache, eine graphförmige, projektionsbasierte Query-Sprache, konzipiert für die Art von Joins und Filtern, die Headless-CMS-Inhalte brauchen. Sie ist ausdrucksvoller als GraphQL für Document-Graph-Abfragen. Der Nachteil ist, dass GROQ Sanity-spezifisch ist, also bedeutet eine zukünftige Migration weg von Sanity das Umschreiben jeder Query. Für die meisten Teams überwiegt der Produktivitätsgewinn kurzfristig das Lock-in-Risiko.

Sanity in 2026: wo es wirklich gewinnt (und wo Payload es schlägt)