Three Headless CMSes Walk Into a Bar

Sanity filed a pull request to order. Contentful added 'beer' to the drinks content type. Storyblok dragged a glass into a visual block. Only one of them can explain who approved it.

Where does your content schema live? Not the content itself: the definition of what the content can be. Field names, types, relationships, constraints.

Sanity puts it in your codebase. Contentful puts it in a database you manage through a UI or API. Storyblok gives you a visual editor and stores it in their platform. Each position is coherent. None is universally correct.

The Three Positions

Sanity, Contentful, and Storyblok each make a different structural bet about where schema definition lives. Here is what that looks like concretely.

What Schema-as-Code Gets You

When schema lives in code, it participates in the full software development lifecycle: reviewed, tested, deployed alongside the application that depends on it. Migration scripts sit next to the schema changes that require them. The tradeoff: every change requires a developer. A content strategist cannot add a metadata field without opening a branch.

There is also a subtler cost: schema drift. Your TypeScript files define what Studio enforces for new content. They do not retroactively reshape old content. A field added six months ago with no validation constraint now has 400 documents that predate it. Sanity will not stop you querying for a field that half your documents were created without.

What Schema-as-Data Gets You

Contentful stores schema in the same database as content. Changes are instantaneous. A content ops team can add a field, test it in staging, and publish it without touching a deployment pipeline.

The risk: without discipline, environments drift. A content type in staging that never made it to production. A field added to production with no schema export to show for it. Contentful's Migrations CLI recovers most of this: write schema changes as versioned scripts, track them in source control. Teams that skip it end up rebuilding Sanity's model manually, without the type safety.

The Dimension That Determines the Answer

The right architecture depends on one question: who needs to be able to change the schema, and how fast?

None of these is wrong. They are optimising for different constraints. The mistake is selecting a platform based on feature lists and discovering the governance model six months into the project.

Platform Portraits

Sanity is the engineer who version-controls their grocery list. Correct, auditable, and requires a pull request to add a checkbox.

Contentful is the product manager who runs everything through a spreadsheet. The spreadsheet is very good. It diverges from production if you stop updating it.

Storyblok is the visual thinker who needs to see it to design it. The type safety conversation happens later, usually when it matters.