How AI is powering better personalization in e-commerce [with Vercel]. Sign up now
When Contentful's limits become walls

You're stuck at 49 of 50 content types. Again.

Sanity vs Contentful G2 Satisfactions Scores
The operational reality check

What Contentful's sales team won't tell you

Sanity

Sanity

Comparison

Contentful

Sanity
Supported
Easily configurable conditional fields, field groups/tabs, initial values for any type, and validations.
Contentful
Limited
Limited out-of-the-box options, or else requires custom components
Why it matters
Smart content forms out of the box vs build everything beyond basics yourself
Sanity
Data-driven and framework agnostic, click-to-edit, available on free and up
Contentful
Contentful Studio on custom plans only, React-only requires significant developer work to implement
Why it matters
Visual editing should be for everyone and fit your stack
Sanity
Supported
Fully extensible Portable Text Editor with inline blocks, annotations, and styles
Contentful
Limited
Remove features only, can't add, blocks has to be references
Why it matters
The formatting you need vs what they allow
Sanity
Supported
Flexible content types in documents
Contentful
Limited
Rigid entry-reference model
Why it matters
Natural content flow vs forced fragmentation

This table is based on public docs and user reports as of March 2026.
Operational reality

What breaks teams in production

Sanity

Sanity

Comparison

Contentful

Sanity
Supported
Per IP address (each user/service gets full limits)
Contentful
Limited
Per space (entire organization shares one limit)
Why it matters
100 editors? Still 10 req/s total. Migration script? Everyone stops work.
Sanity
Supported
25 req/s per IP
Contentful
Limited
7-10 req/s for entire space
Why it matters
"Mission-critical systems competing with auxiliary systems" - actual user quote
Sanity
500 req/s pr IP, unlimited CDN
Contentful
55-78 req/s pr space, unlimited CDN
Why it matters
When your CI/CD pipeline hits rate limits, content publishing stops.
Sanity
100mb query size, 1GB response
Contentful
8KB query, 7MB response
Why it matters
TOO_COMPLEX_QUERY error becomes a frequent blocker
Sanity
Supported
Thousands of doc mutations per mutation/action
Contentful
Limited
200 items max, 5 concurrent, only publish actions
Why it matters
10,000 products? 50 separate operations. At 10 req/s = blocked for hours
Sanity
Supported
Live Content API (CDN), Instant push
Contentful
Not supported
Webhook polling only
Why it matters
"Is it live yet?" becomes minutes of waiting

This table is based on public docs and user reports as of March 2026.
The results are in

Sanity is ranked #1 out of 85 CMSes on G2

Read G2 reviews
G2 Winter 2026 Grid chart with 'Leader' designation, showing multiple companies plotted and a large G2 logo.

Trusted by 2000+ leading brands

  • Figma
  • Anthropic
  • Brex
  • Shopify
  • Linear
  • Skims
  • Unity
  • loveholiday
  • Expedia Group
  • Mejuri
  • Replit
  • Tecovas
  • PUMA
  • MoMA

Things people often ask about us versus Contentful

How does Sanity's "schema-as-code" approach benefit our development team over Contentful's UI-based modeling?

We see daily how Sanity's schema-as-code approach offers significant advantages for development teams. By defining content models in JavaScript or TypeScript, developers can version control schemas using Git, just like any other piece of code. This enables better collaboration, code reviews, and seamless integration into CI/CD pipelines. Oh, and AI can totally assist in this work.

In contrast, Contentful's UI-driven content modeling can be more restrictive and lead to a disconnect between the content structure and the application code. Sanity gives developers the flexibility to build complex, nested data structures without being confined to a graphical interface.

My team is concerned about vendor lock-in and customization limitations. How does Sanity address this compared to Contentful?

Sanity is designed to be highly customizable and prevent vendor lock-in. Sanity Studio, the editing interface, is an open-source React application that developers can completely customize to fit specific workflows and business needs. With App SDK, developers can also stand up standalone apps that can work across an organizations projects and datasets.

This level of control is not possible with Contentful's proprietary and more rigid App Framework. Sanity's open architecture and flexible data modeling empower developers to build truly bespoke solutions.

We're focused on performance and scalability. How does Sanity's architecture compare to Contentful's?

Sanity is built for real-time applications and offers excellent performance and scalability. Its "Content Lake" architecture is designed for low-latency queries and real-time data syncing, making it ideal for dynamic and collaborative applications. We run sophisticated global infrastructure that can deliver real-time content over the CDN for both public and private content.

While Contentful relies on a traditional CDN-based approach for content delivery, Sanity's real-time capabilities provide a more responsive experience for both editors and end-users. Sanity's GROQ query language is another key advantage, allowing for efficient and precise data fetching.

How can Sanity improve our content team's workflow and efficiency compared to Contentful?

Sanity's real-time collaboration feature is a significant advantage for content teams, allowing multiple editors to work on the same document simultaneously without the risk of overwriting each other's work.

This is a feature that is limited in Contentful lacks. We were able to create race conditions and data loss in our testing of their interface.

Furthermore, the ability to customize the Sanity Studio means you can create a tailored editing experience that matches your team's specific needs and workflows, ultimately boosting productivity.

We want to create unique and engaging content experiences. How does Sanity empower us to do that in ways that Contentful might not?

Sanity's flexibility and developer-friendliness directly translate to the ability to create more innovative content experiences. The customizable nature of Sanity Studio allows for the creation of bespoke editing interfaces that can include features like in-line previews and custom components, giving content creators more control and a better understanding of the final output.

This level of customization is not as easily achievable in Contentful's more rigid environment.

We're concerned about the total cost of ownership. How does Sanity's pricing model compare to Contentful's, especially as we scale?

Sanity's usage-based pricing model can be more cost-effective, especially for growing teams. You pay for what you use, which provides greater flexibility and predictability in your expenses. You also get more features on lower tiers, as Sanity's philosophy is to earn team's trust by letting them build and validate the value.

Contentful's tier-based pricing can quickly become expensive as you add more users, content types, or locales, leading to significant cost increases as your needs evolve. They tend to prioritize enterprise for new features.

For example, a setup with 5 users and 30 content types could be significantly more affordable on Sanity's Growth plan compared to Contentful's Lite plan with a Lite Space add-on.

How do Sanity's APIs and programmatic capabilities compare to Contentful's for managing content at scale?

Sanity provides a more flexible and powerful set of tools for programmatic content management. While both platforms offer robust APIs, Sanity's GROQ (Graph-Relational Object Queries) query language gives developers a significant advantage for fetching and manipulating content with a high degree of precision.

This, combined with Sanity's real-time APIs, enables more dynamic and responsive applications. For developers looking to build custom integrations and automate content workflows, Sanity's API-first architecture and flexible data model provide a more powerful and less restrictive environment than Contentful's.

My team is looking for a solution that allows for true version control and a "Git-like" workflow for content. How does Sanity's approach to content modeling support this?

Sanity's "schema-as-code" approach is a game-changer for development teams that value version control and collaboration. By defining content models in JavaScript or TypeScript, you can manage your content schema in the same way you manage your application code—with Git. This enables branching, pull requests, and code reviews for schema changes, which is a significant improvement over Contentful's UI-based content modeling.

This approach reduces the risk of unintended changes and provides a clear history of how the content model has evolved over time.

We often hear from earlier Contentful customers that they had to lock down the Content type configurations, because non-developers would accidentally break their site by changing the content model and thus the API signature.

We want to provide our content team with the best possible editing experience, including visual editing and live previews. How does Sanity's offering compare to Contentful's?

Sanity's open-source Sanity Studio provides a superior and more customizable visual editing experience. Because the Studio is a React application, it can be fully tailored to your team's specific needs, including the creation of bespoke in-line previews that show content exactly as it will appear on the front end. This level of customization is not possible with Contentful's more rigid, out-of-the-box interface. Furthermore, Sanity's real-time collaboration capabilities allow multiple editors to work on the same content simultaneously, which is a significant advantage for team productivity.

Our content strategy requires a lot of flexibility in how we structure and relate content. How does Sanity's approach to content modeling give us an advantage over Contentful?

Sanity's flexible, code-driven approach to content modeling empowers you to create the exact content structures your product needs, without the limitations of a GUI-based system. This means you can easily create complex, nested content structures and define relationships between different pieces of content in a way that is more difficult to achieve in Contentful. This flexibility is crucial for product owners who want to create rich, interconnected content experiences and future-proof their content strategy.

We've heard that "code-first" platforms like Sanity can be slower to get started with compared to Contentful's GUI-based approach. Is that true?

That's a common misunderstanding, but the opposite is often true, especially when you consider the entire project lifecycle. While Contentful’s GUI might seem faster for initial setup, Sanity's code-first approach accelerates development in the long run. You will also get instant visual feedback when you build out the editorial experience, unlike in Contentful where you have to click and navigate back and forth in their hosted UI to see the effects of changes.

By defining your schema in code, you can leverage version control, reuse configurations across projects, and integrate with CI/CD pipelines for more reliable and faster deployments.

With the rise of agentic coding and AI-powered development, having your content model as code allows you to programmatically generate, test, and update schemas, which is a significant speed advantage over manual, UI-based modeling.

My team is concerned about the learning curve of a "code-first" system. How does Sanity support a fast time-to-market?

Sanity provides a rich "out-of-the-box" experience that allows you to get up and running in minutes. You can start with pre-built templates and a fully-featured, open-source studio that can be customized as needed. You only need to define content types with a few lines of code and a simple command line to deploy your Studio for your content team. Sanity Studio ships with a lot of features out of the box that you might have to install as additional plugins in a Contentful project, and fast configuration options that's not possible to do with Contentful without resolving to UI customization, conditional fields being one example.

The "code-first" aspect doesn't mean you're starting from scratch; it means you have the power to extend and adapt without limitations. This is a key part of our evolution into a Content Operating System—we provide the core infrastructure, including the Sanity Studio and our Content Lake, so your team can focus on building custom applications and workflows on top of a solid foundation, rather than being constrained by a rigid UI.

Contentful seems more straightforward and "out-of-the-box." How can Sanity's approach be better for my content team?

While "out-of-the-box" can sound appealing, it often means you have to adapt your workflows to the software. It's more "into-the-box" or the box is really shallow once you start poking at it.

Sanity’s approach is to provide a powerful, customizable platform that adapts to your team's needs. We design the platform with great defaults and progressive disclosure, so you can get started quickly and then customize as you learn.

We've evolved beyond just a CMS into a Content Operating System, which includes a central Dashboard with Apps, and Canvas for a more visual, collaborative workspace.

This means you can create a tailored editing experience that matches your team's exact workflow, which boosts efficiency and adoption. It's the difference between a one-size-fits-all tool and a custom-built solution that empowers your team to do their best work.

How does Sanity's new "Content Operating System" model provide more value than a traditional headless CMS like Contentful?

The Content Operating System is a fundamental shift from the limitations of a traditional headless CMS. It’s an engineering platform that treats content as a core business asset. This means you're not just getting a place to store and edit content; you're getting a platform to build content-powered applications.

For example, with our App SDK, your developers can build custom dashboards and tools directly into Sanity, creating a central hub for all your content operations.

This allows you to create highly specific, efficient workflows that are simply not possible in a more constrained system like Contentful. It's about future-proofing your content strategy and giving you the tools to innovate, rather than just manage.

How Sanity stacks up against contentful

This is our point of view on Contentful as builders in the CMS space for over a decade.

When you're suddenly out of content types and realize you need to delete something to add something new? When your editors are copy-pasting from Google Docs because the CMS is too painful? When you're running migration scripts at 2am because changing a field means touching every piece of content?

That's not how content operations should feel. That's what we hear building with Contentful feels like.

What developers who switched tell us

We've watched hundreds of teams migrate from Contentful to Sanity. Here's what they say made the difference: radically better flexibility and customization. Not the "configure it in our UI" kind, but the "shape it exactly how your team works" kind.

Here's what we think actually matters when you're choosing between us.

The thing about flexibility

Or: why Content Lake vs CMS matters

In our view: Contentful wasn't designed for true flexibility. They built a CMS in the browser with an opinionated API on top. At Sanity, we built a Content Lake, a database where your content is the source of truth, not our interface.

This fundamental difference shows everywhere. With Contentful, you're configuring their system through their UI. With Sanity, you're defining your content model in code, version-controlled alongside your application. With hot-module-reloading to instantly see how the editor experience turns out. Your content exists as structured data that you can shape, query, and transform however you need.

We see customers moving from Contentful because of this. It's hard to spot at first, but you slowly feel the walls closing in as your project matures. What seemed like helpful guardrails become permanent constraints.

The type ceiling you'll hit

Here's what a developer working on a major Contentful enterprise account recently told us: they're stuck at 149 out of 150 content types. Dead in the water. Can't add the second report type their client needs without deleting something else. Or go into contract negations.

This isn't edge-case stuff. Contentful forces everything to be references: no inline objects in documents. Every reusable button? That's a content type. Every SEO block? Another type. That single document list in Contentful becomes a junkyard of loose content pieces, differentiated by emojis because that's all you've got.

With Sanity, you decide what should be reusable references and what should be inline. You can tailor document lists to be exactly what you need.

Your content model, your rules.

Migration impossibility

Changing your mind seem to cost extra with Contentful. Need to restructure content? It's hard to do schema change management. You soft-deprecate by hiding fields because deletion is destructive. Their "solution" for evolving content models is making you accumulate cruft until your schema looks like archaeological layers.

It's like they are not incentivized to let you get rid of content types.

With Sanity? Update multiple documents in a single transaction. Use createOrReplace and patch for smart upsert. Provide determinstic IDs for predictable migrations. Our transaction API means you can refactor confidently: no hoping that API call #3 doesn't fail after #1 and #2 succeeded. Our schema migration tooling gives you just-enough-abstraction to scaffold, write, validate, and run schema and content migrations efficiently.

When preview becomes a puzzle

Let's talk about that "superior editorial experience" Contentful claims.

Want live preview? Digging into their docs, you'll discover that it entails adding 5-10 lines of boilerplate to every single component. Want to change a button? Better remember that button might be referenced on 17 other pages: hope you meant to change them all. Need to preview changes? Publish the referenced documents first (separately), then refresh the preview. We think all of that should just work, including previewing draft versions of your references.

What might look nice and clean in that demo or in the start, quickly becomes messy. And content creators risk subtly breaking stuff unless engineering has spent a lot of time adding all the safe guards.

One agency showed us their workflow: editors work in Google Docs, developers copy-paste into Contentful. That's not a content management system, that's expensive manual labor and wasted engineering time.

Meanwhile, with Sanity you can start writing free-form content with AI assistance in Canvas, and then automatically map it directly to your fields in the Studio. You can give different teams completely different Studios and specialized content ops apps. Your merchandisers get their e-commerce interface. Editors see authors and posts. Not just permissions, completely tailored interfaces that make sense for each team's actual job.

And all working on the same single-source-of-truth content.

The AI development gap

While Contentful makes you click through their UI to add fields one by one, our developers are building entire content models in minutes. They screenshot a Figma design, describe what they want to an AI agent, and get working schemas.

Contentful offer Agent Actions through a simple GUI dashboard (you can trigger it via an API call). And… that's it.

Developers using Sanity can deploy Functions with Agent Actions and their own business logic that automatically triggers on any content change made by humans/agents and does the work automatically: with full attribution and transparency. And without causing race conditions.

Here's the kicker: Sanity Functions use GROQ patterns for surgical precision. Trigger only when the body changes AND contains "sale" AND price < 10. Try setting that up in Contentful's webhook panel.

The agent even understands your schema.

Using AI development tools with Sanity means actually developing with AI. With Contentful, it means asking AI where to click next.

True composability vs. "headless"

While Contentful talks about being "composable," they're still surprisingly opinionated about how you structure and access your content. True composability means you can swap out any part of your stack: including how your content is modeled, stored, and delivered. It's what they call interoperability.

Contentful's reference-only architecture makes this surprisingly rigid. You can't refactor your content model without touching every piece of content. You can't optimize queries without their specific GraphQL limitations. You can't build the editorial UI your team actually needs. You can't easily update content programmatically either.

Sanity gives you the same powerful mutation APIs that our editing environment uses for real-time updates. It's pretty wild: You can actually point to a specific nested property in a JSON document and conditionally patch it in a transaction. If you don't understand what that means, hopefully it sounds cool that you can (but it's also pretty useful!)

Real-time by default

The difference between a CDN and a Live Content API

Contentful gives you a standard CDN. Sanity give you a Live Content API where the CDN automatically updates only what changes, and your front-end can subscribe to updates.

No refresh needed—disable that "Add to cart" button the instant inventory hits zero. Show breaking news as it happens. Update prices across all channels simultaneously. This isn't a feature you configure. It's just how Sanity's content API works.

What 300 Contentful customers said

A December 2024 study surveyed 300 actual Contentful users. The highlights:

  • 45% reported sluggish performance during normal usage
  • 40% struggled with basic navigation and setup
  • 35% needed more customization but hit platform limits
  • 30% worried about scaling costs
  • 25% found collaboration tools inadequate for real projects

These aren't competitors talking. These are their customers. And these are only the ones who realize that you can have higher expectations to your CMS.

When Contentful might work for you

Let's be honest. Contentful can be fine if:

  • Your content model is simple and unlikely to evolve
  • You have a small team with clearly defined roles
  • You prefer GUI-based CMS configuration over code
  • You're building a straightforward marketing site with standard requirements (and no ambitions to expand it)

If that's you, Contentful might genuinely be enough. We built Sanity for everyone else.

Things you can actually do in Sanity

(that you can't neatly do with Contentful)

✓ Define your entire content model in code
✓ Have unlimited content types (not 150) and locales
✓ Use inline objects, even in rich text
✓ Build custom editorial interfaces that match your workflow
✓ Create multiple Studios for different teams
✓ See all your content as actual JSON in the dashboard
✓ Generate schemas with AI in your favorite IDE
✓ Actually migrate content without risking overwriting data
✓ Version control your content model alongside your code
✓ Give editors a UI that makes sense for their actual job
✓ Query your content with a language built for content (not generic data)
✓ Copy and paste entire field values (complex objects, not just text)
✓ Build purpose-specific content apps beyond just the Studio
✓ Subscribe to real-time content updates without polling

The technical reality

For the developers who want specifics:

Content modeling: Contentful locks you into their UI with hard type limits. Sanity has no artificial limits on content types: you'll hit their limit way before you hit our technical constraints.

Field types: Contentful forces everything to be references. Sanity supports both inline objects and references. Use what makes sense.

Validation: Contentful gives you a subset of regex. Sanity gives you full JavaScript validation. Write the rules you actually need and that helps your content team.

Query language: Contentful offers generic REST/GraphQL. Sanity built GROQ specifically for content: query content as data.

Real-time collaboration: Contentful's is slow and prone to race conditions. Sanity is fast and shows you who's working where. Even agents.

Migration: Contentful requires custom API scripts and prone to accidental content deletion. Sanity supports declarative migrations that actually work.

Customization: Contentful limits you to UI extensions. Sanity lets you build full React components: your UI, your way. With fast local developer experience.

AI development: Contentful's AI stops at their UI. Sanity supports full code generation. Let AI build your entire content model, even custom content operations apps.

Already invested in Contentful?

We get it. Migration feels daunting. You've got content, you've got workflows, you've got a team that finally knows where to click.

Here's what teams who've made the switch tell us: the migration itself took weeks, but they got months of development time back in the first year. No more wrestling with reference puzzles. No more content type Tetris. No more "sorry, that customization isn't possible."

We've built migration tools specifically for Contentful. Your content comes over structured and clean. Your team gets trained on a system that actually makes sense. Our solution and support engineers have done this migration many times before.

Why this matters now

Every workaround you build in Contentful becomes technical debt. Every content type you carefully ration delays your next feature. Every reference-publishing puzzle your editors solve is time not spent on actual content.

The architectural decisions Contentful made years ago, Everything as references, UI-based configuration, rigid type limits: these aren't bugs. They're features of a business model that profits from deliberate constraints.

The bottom line

We built Sanity because we were tired of content systems that made easy things hard and hard things impossible. Where Contentful gives you forms to fill out, we give you code to shape. Where they count your content types, we let you model freely. Where they lock you into their UI, we let you build your own.

This isn't about features. It's about fundamentally different philosophies. Contentful believes they know how you should work. We believe you know better than anyone.

What's next?

Just evaluating?

Start with our free tier and 30 day Growth trial →
Build something real with most of the features, and see how different it feels when your content system works with you, not against you.

Stuck on Contentful?

Talk to our sales team →
We've helped enough teams make the move to know exactly what works, what doesn't, and how to preserve your content while upgrading your capabilities.

P.S. If you're reading this while waiting for Contentful's preview to refresh, or trying to figure out which of your 147 content types you can sacrifice to add a new feature... yeah, we built Sanity for you.

Get a custom demo today

By submitting this form, you confirm that you have read and understood Sanity's Privacy Policy. This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.