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 versus the Payload-or-Storyblok crowd, you've already eliminated 80 percent of the noise that the rest of this category emits. The remaining decision is the interesting one: are you optimising for the editorial team's experience, or for the engineering team's ownership? Get that question right and the rest of the choice is mostly forced.

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, bei dem du das Schema in TypeScript oder JavaScript schreibst, eine anpassbare React-basierte Admin-App namens Sanity Studio (normalerweise in deiner eigenen Domain deployed) ausführst und den Inhalt über GROQ abfragst -- eine graphähnliche Abfragesprache, die GraphQL ähnelt, aber bei Dokumentbeziehungen ausdrucksvoller ist. Inhalt ist out of the box echtzeit-synchron ü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 Kostenentwicklung

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.
25.000 Dokumente Hard Cap -- kein Pay-as-you-go über diesem Limit 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-Vorschauen, Custom-Workflow-Buttons, Custom-Validierung, Custom-Asset-Pipelines -- alles lebt 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, bei dem du das bauen kannst, ohne dich mit der Plattform anzulegen.

GROQ als Query-Sprache

GROQ ist bei Dokument-Graph-Abfragen ausdrucksvoller als GraphQL. Du kannst über Referenzen hinweg joinen, verschachtelte Felder projizieren, auf berechnete Werte filtern und Listen in einer einzigen Abfrage slicen. Der Trade-off ist, dass GROQ Sanity-spezifisch ist -- du kannst deine Abfragen nicht anderswohin mitnehmen. Für Teams, die komplexe Content-Oberflächen ausliefern (facettierte Verzeichnisse, verwandte-Inhalte-Widgets, mehrsprachige 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 Sanity's gehosteter Infrastruktur -- für die meisten Teams in Ordnung, ein K.O.-Kriterium für regulierte Industrien oder jedes Team mit einer „Keine-Third-Party-Data-Store"-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.Payload vs Strapi in 2026. The short version is the same shape: Payload for TypeScript-heavy teams that want ownership, Strapi for teams that want a richer plugin ecosystem.

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-Inhalt über WP All Export exportieren, in Sanity's NDJSON-Dokumentformat transformieren, über die Sanity CLI importieren. Das Schema-Mapping ist die Arbeit -- Pages, Posts, Custom Post Types, ACF-Felder brauchen alle ein Sanity-Äquivalent. Das WordPress-to-Next.js-Migrations-Playbook deckt die SEO-Transport-Seite ab, die unabhängig vom CMS-Ziel anwendbar ist. Zeit bei einer 5.000-seitigen Website: 4 bis 8 Wochen konzentrierte Arbeit nur für die Migration selbst, länger wenn das Schema komplexe relationale Inhalte beinhaltet.The WordPress to Next.js migration playbook covers the SEO transport side that applies regardless of CMS target. Time on a 5,000-page site: 4 to 8 weeks of focused work for the migration alone, longer if the schema includes complex relational content.

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 2026: ja -- Sanity bietet mehr Schema-Flexibilität, bessere Echtzeit-Zusammenarbeit, eine fähigere Abfragesprache (GROQ) und eine bedeutend niedrigere Preisgestaltung für äquivalente Feature-Sets. Contentful's Stärke liegt in Enterprise-Beschaffung und Integrationen mit Legacy-Marketing-Stacks. Wenn dein Team technisch versiert ist und der Editorial-Workflow die Priorität ist, ist Sanity die bessere Wahl. Wenn deine Stakeholder einen beschaffungsfreundlichen Enterprise-Vertrag fordern, ist Contentful die sichere Wahl.

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

Im Growth-Plan zahlen Sie $75 pro Monat für 5 Plätze à $15 pro Platz. Benötigen Sie SAML SSO, addieren Sie $1.399 pro Monat – wodurch dasselbe Team $1.474 monatlich kostet. Der kostenlose Plan deckt 20 Plätze mit harten Limits ab. Ist Ihr Team klein und die Nutzung niedrig, kann der kostenlose Plan Sie das erste Jahr über tragen.

Kann ich Sanity mit Next.js verwenden?

Ja – Next.js ist 2026 das häufigste Frontend für Sanity. Das offizielle @sanity/client Package handhabt die API-Aufrufe, GROQ-Queries laufen serverseitig in Server Components oder über API Routes, und Visual Editing wird im Preview-Modus unterstützt. Sanity stellt ein gepflegtes Next.js-Starter-Template zur Verfügung; es zu klonen ist der schnellste Weg zu einem funktionierenden Projekt.

Was ist GROQ und warum ist es wichtig?

GROQ ist Sanitys Content-Query-Language – eine graphförmige, projektionsbasierte Query-Language, die für die Art von Joins und Filtern konzipiert ist, die Headless-CMS-Inhalte benötigen. Sie ist ausdrucksstärker als GraphQL für Document-Graph-Queries. Der Nachteil ist, dass GROQ spezifisch für Sanity ist. Eine künftige Migration weg von Sanity bedeutet, jede Query umzuschreiben. Für die meisten Teams überwiegt der Produktivitätszuwachs kurzfristig das Lock-in-Risiko.

Pick your view

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