These three get compared constantly, which is odd, because only two of them are the same kind of product. Any Payload CMS vs Contentful comparison has to start there.
Sanity and Contentful are hosted services. You pay them, they run the infrastructure, your content lives in their system. Payload is software you run yourself. There is no invoice from Payload; there is infrastructure you own and operate.
That is not a feature difference. It is a difference in what you are buying, and it means the comparison cannot be settled on a feature table. What follows is the honest shape of the trade: where each model’s cost actually lands, and which limits stop you first.
The Payload CMS vs Contentful cost model, and what it is attached to
Contentful offers a genuinely usable free tier: 10 users, 100,000 API calls a month, 50 GB of CDN bandwidth, and one space with 25 content types and 10,000 records. The caps are hard. You are not billed for overage, you are stopped.
Above that, the Lite tier runs $300 a month, roughly doubling those allowances to 20 users, 1 million API calls and 100 GB of bandwidth. Beyond that sit Premium and Enterprise, which are custom-quoted. Third-party procurement data puts SMB contracts in the region of $36,800 a year and enterprise contracts near $179,000. Those are reported averages rather than published prices, but the order of magnitude is the point. Current figures are on Contentful’s pricing page.
Sanity prices differently: $15 per occupied seat per month on the Growth plan, with viewers free. The free tier includes two datasets. Growth allows 1 million CDN requests, 100 GB of bandwidth and 100 GB of assets, with pay-as-you-go overage at roughly $1 per additional 250,000 CDN requests and $0.30 per extra gigabyte.
Add-ons sit on top of that: dedicated support at $799 a month, an increased-quota bundle at $299 a month, and additional datasets at $999 each per month. The current table is on Sanity’s pricing page.
Payload has no licence fee at all. It is MIT-licensed and self-hosted, so what you pay for is infrastructure: a database, object storage for media, an email provider and a CDN. Realistically that is $25 to $60 a month for a small content site, $80 to $250 for a business site with real staging and a meaningful media library, and $300 and up for multi-market or media-heavy builds.
Since Payload Cloud paused new sign-ups following Figma’s acquisition, new projects self-host by default. Our note on Payload CMS hosting and cost in production goes through what that involves.
| Hosted (Sanity, Contentful) | Self-hosted (Payload) | |
|---|---|---|
| Scales with | Seats, API calls, bandwidth, documents | Infrastructure and engineering |
| Upfront | Low | Higher |
| Predictability | Good until a threshold, then a step change | Flat, and yours to forecast |
| Who operates it | Them | You |
| Cost of doing nothing | Rises with traffic and team size | Roughly flat |
The uncomfortable part of hosted pricing, and the heart of Payload CMS vs Contentful on cost, is that it is metered on things that grow whether or not the business does. Traffic grows, the content library grows, the team grows. Revenue may or may not keep pace.
Self-hosting swaps that exposure for a different one: operational work that has to be staffed whether or not anyone is currently thinking about the CMS. That is the real Payload CMS vs Contentful trade, and it is a trade rather than a winner.
Payload CMS vs Contentful: the limits that actually stop you
This is the part missing from most Payload CMS vs Contentful comparisons, and it matters more than the headline price. The constraint that bites is rarely the one you were watching.
Contentful: content types, not API calls. The starter space allows 25 content types. That sounds generous until you model a real site: articles, authors, categories and tags, plus a page-builder block set where each block type is its own content type. Teams burn through 25 faster than they expect.
And this is not a cost limit you can pay your way past incrementally. It is a modelling limit, which means hitting it stops you expressing your content properly rather than just costing more.
Contentful: roles. Two roles on Free, three on Lite. If the editorial workflow needs author, editor, approver and translator as distinct permissions, that is a Premium conversation, and Premium is custom-quoted.
Sanity: datasets. Extra datasets cost $999 each per month, capped at four in total on Growth. If the architecture calls for a dataset per market or per brand, that is a cliff rather than a slope.
Sanity: seats at scale. $15 per occupied seat is inexpensive for a team of five and a real line item for a team of forty. It is also the dimension that grows for reasons unrelated to the CMS. Someone joins marketing, the bill goes up.
Payload: none of the above, and one of its own. There is no seat limit, no API call meter, no content type ceiling and no per-dataset charge. The constraint is that everything above is now your responsibility. Nobody sends you a bill when traffic doubles; somebody on your side has to notice and scale the database.
Editor experience
Worth being straight about this, because it is the one part of Payload CMS vs Contentful where hosted platforms genuinely lead and where a self-hosted advocate is tempted to be vague.
Sanity Studio is excellent. Real-time collaborative editing, with several editors in the same document seeing each other’s changes as they happen, is the strongest editorial experience of the three and is not trivial to replicate. For content-heavy publishing operations where multiple people work the same pieces simultaneously, this is a real and continuing advantage.
Contentful is mature and familiar. It has been the default enterprise headless CMS for long enough that many editors have used it before, and the interface is stable, well-documented and predictable. Onboarding a new content hire costs less when the tool is one they already know.
Payload’s admin is customisable rather than polished by default. This is a genuine difference and it cuts both ways. Out of the box, the admin is clean and competent but not remarkable. What it offers instead is depth of customisation: fields, validation, and entire custom admin components built for your editors’ actual workflow rather than a generic one.
In practice that means the ceiling is higher and the floor requires investment. A Payload admin built with real design effort can fit a specific editorial process better than either hosted option, because it was built for that process. A Payload admin left at defaults is worse than Sanity Studio. Which one you get is a project decision rather than a platform property, so in any Payload CMS vs Contentful estimate it should be budgeted explicitly rather than assumed.
Developer control in Payload CMS vs Contentful
Here the direction of the Payload CMS vs Contentful comparison reverses.
Payload runs inside your application. Since v3 it lives in the Next.js project itself: one deployment, one codebase, full TypeScript types generated from your schema, and a local API that reads content server-side without a network round trip.
Content modelling is code, which means it goes through review, sits in version control, and moves between environments the same way the rest of your application does. The Payload deployment docs set out what running it involves.
Sanity’s content model is also code. Studio is configured in JavaScript and version-controlled, which puts it closer to Payload than Contentful on this axis. But the content itself lives in Sanity’s hosted datastore and reaches your application over their API.
Contentful is the most decoupled and the most managed. Content models are typically built in the web UI, which is friendlier for non-developers and harder to review, diff, or promote between environments in a disciplined way.
There is also a practical point about limits that shapes the Payload CMS vs Contentful choice. With Payload, when something does not do what you need, it is your code and you change it. With a hosted platform, you file a request or work around it. Neither is universally better: you can change anything is also you are responsible for everything.
Data ownership, and why it matters more in this region
With Payload, your content sits in your own Postgres or MongoDB, on infrastructure in accounts you control. With Sanity and Contentful, your content lives in their system and comes out through their APIs and export tooling.
For most projects this is an abstract distinction. Three situations make it concrete, and each one changes the Payload CMS vs Contentful answer.
Exit cost. Leaving a hosted CMS means an export, a transformation, and a rebuild of whatever the platform was doing for you. Leaving a self-hosted system means moving a database. The second is not free, but it is a known quantity.
Pricing changes. A hosted vendor can reprice, restructure tiers, or move a feature you depend on into a higher plan. Self-hosting removes that exposure entirely. Your infrastructure provider can reprice too, but you can move providers in a weekend.
Data residency. This is the one that matters most for teams selling into Singapore, Malaysia and the UAE. Where regulation or a customer contract requires content and personal data to be stored in a specific jurisdiction, self-hosting answers the question directly: you choose the region.
With a hosted platform the answer depends on what regions that vendor offers and on what tier. It is a question worth asking early rather than during a security review, and in a Payload CMS vs Contentful decision it is often the point that settles things.
The Payload CMS vs Contentful decision, in shape rather than verdict
| Payload | Sanity | Contentful | |
|---|---|---|---|
| Model | Self-hosted, MIT | Hosted | Hosted |
| Cost driver | Infrastructure and engineering | Seats and usage | Seats, API calls and tier |
| First limit hit | Your own ops capacity | Datasets, seats | Content types, roles |
| Editor experience | As good as you build it | Best-in-class collaboration | Mature, familiar |
| Content model lives | In your code | In code | Usually in the UI |
| Data location | Wherever you choose | Their infrastructure | Their infrastructure |
| Best suited to | Teams on Next.js wanting control and owning infrastructure | Content-heavy publishing with simultaneous editors | Large organisations wanting a managed standard |
Across the Payload CMS vs Contentful projects we have delivered, three patterns hold up consistently.
Payload fits where the team already lives in Next.js, where the admin needs to match a specific editorial workflow rather than a generic one, where data location is a requirement rather than a preference, and where there is engineering capacity to own infrastructure.
Sanity fits where several editors work the same documents at the same time, where the content operation is the product, and where the team would rather pay per seat than run servers.
Contentful fits where a large organisation wants a managed standard with procurement, compliance and support already answered, and where the content model is stable enough to live comfortably inside the tier’s limits.
And one closing note on how to choose, because it is where these decisions usually go wrong: model your second year, not your first. All three are inexpensive at the start, which is why a Payload CMS vs Contentful comparison made in month one rarely survives month eighteen. The hosted options become expensive through growth in things you do not directly control, such as traffic, team size and content volume. The self-hosted option becomes expensive if nobody is available to operate it.
Those are different risks, and which one you would rather carry is the actual decision behind Payload CMS vs Contentful. If you want the same treatment against Strapi, we wrote Payload CMS vs Strapi: an honest comparison as well.
Frequently asked questions
Is Payload cheaper than Contentful?
It has no licence fee, which is not the same as cheaper. Payload costs infrastructure, roughly $25 to $300 a month depending on scale, plus the engineering time to operate it. Contentful costs $0 on a capped free tier, $300 a month on Lite, and custom pricing above that. In a Payload CMS vs Contentful comparison, which is cheaper depends on whether your constraint is money or people.
What is the real difference between Payload and Contentful?
Contentful is a hosted service, so your content lives in their system and you pay them for seats, API calls and tier. Payload is MIT-licensed software you run yourself, so your content lives in your own database and you pay for infrastructure. That is a difference in what you are buying, not a feature difference.
Which limit do teams hit first in Payload CMS vs Contentful?
On Contentful, content types: 25 on the starter space, which a real page-builder site burns through quickly, and it is a modelling limit rather than one you can pay past. On Sanity, datasets at $999 each per month. On Payload, your own operations capacity. In a Payload CMS vs Contentful decision that is usually the deciding difference.
Is Sanity Studio better than the Payload admin?
Out of the box, yes. Sanity Studio has real-time collaborative editing that is genuinely hard to replicate. Payload’s admin is customisable rather than polished by default, so a Payload admin built with real design effort can fit a specific workflow better, and one left at defaults is worse. That is a project decision, not a platform property.
Which option answers a data residency requirement?
Self-hosting answers it directly, because you choose the region your database and media sit in. In Payload CMS vs Contentful terms Payload wins this one outright: with a hosted platform the answer depends on the regions that vendor offers and on which tier, so it is worth asking before a contract rather than during a security review.
We build on Payload and we say plainly when a hosted CMS is the better fit, usually when the editorial operation is large and the engineering capacity is not. If you are weighing these three for a specific project, we are glad to look at your content model, your team and your data requirements and give you a straight read. See our Payload CMS development services, or request a CMS fit assessment.