Sanity vs Payload

Sanity and Payload are both code-first and both ship MIT-licensed code, which makes them look closer than they are. The real fork is where content lives: Sanity hosts the backend for you as a managed subscription; Payload is a backend you deploy and own, operated by your team, a partner or Payload. This page lays out where each side wins, then breaks the differences down feature by feature.

The core difference

Sanity is a managed content platform. The Studio — the editing application — is open-source code that lives in your repository and can deploy anywhere, but content itself lives in the Content Lake, a real-time content database that Sanity hosts on Google Cloud and that cannot be self-hosted. You query it with GROQ over Sanity’s APIs, and the operational work of the data layer — scaling, patching, uptime — belongs to the vendor. Since its $85M Series C, Sanity has been building outward from the CMS into a platform of connected products under the “Content Operating System” banner.

Payload is a headless CMS you deploy and own. It installs into a Next.js application, the content model is TypeScript in your repository, and the data sits in a database you choose — Postgres, MongoDB, or SQLite. The admin panel is a React application that ships inside the same codebase as your product. Owning the deployment does not settle who operates it: your own team, a delivery partner, or, for enterprise customers, Payload, whose get-started page lists hosting and dedicated support among what enterprise customers can unlock. The open-source core is MIT-licensed, and it has stayed that way since Figma acquired Payload in June 2025; enterprise features are sold separately.

Schemas are version-controlled code on both platforms, so the deciding question is an operating model: a managed data layer with a subscription and usage meters, or an owned one whose infrastructure and patching are run by your team, a partner or Payload’s enterprise hosting.

Where Sanity is the stronger choice

Sanity earns its keep when running a database is work your organisation should not take on. The Content Lake removes that entire category: no provisioning, no scaling, no data-plane patching, and a SOC 2 Type 2 certificate on the vendor side for the procurement checklist. Its collaborative editing is genuinely ahead — character-level, real-time multiplayer in the Studio is a shipped, mature capability — and Content Agent gives editorial teams AI-driven audits and bulk operations on every plan today.

The Free plan is also a serious on-ramp: twenty seats and quotas most early-stage teams will not hit, at $0, with a full NDJSON export available if you later leave.

Where Payload is the stronger choice

Payload’s case rests on ownership and proximity to the product. Content sits in your own database inside your own compliance perimeter, which for regulated industries and public institutions can be the entire argument. For a TypeScript and Next.js team, the CMS runs inside the same application as the frontend — one deployment, a typed Local API with no network boundary, and schema changes that go through pull requests like everything else.

Its access control is written as code: collection- and field-level access functions, reviewable and auditable in version control, with no plan gate deciding how precise you are allowed to be. And the admin panel is yours to shape: your own React components, shipped through your own release process.

A campaign launch: the same operation on each platform

Take one editorial job and run it through both systems on paper. A spring campaign needs three landing pages in English and German, and one campaign call to action (button text, link and a legal line) that appears on all three. Two agency writers may edit the campaign pages and nothing else, and cannot publish. A marketing lead approves and publishes, and everything goes live at 09:00 on launch day. The mechanics below come from each vendor’s documentation, checked on 29 September 2026. We have not run this operation on either platform, so treat it as an illustration.

Requirement	Sanity	Payload
Two languages	Schema: the official document- or field-level localization plugins; AI Assist translation from Growth up	Schema: core field-level localization with fallback; per-locale publish status is an experimental beta
One shared call to action	Schema: a CTA document referenced from each page	Schema: a CTA collection or global, linked by a relationship field
Writers who cannot publish	Plan: the Contributor role, on Growth and Enterprise, “can write but not publish”	Code: an update access rule that lets writers save drafts only
Writers limited to campaign pages	Plan: custom roles and content resources, which are Enterprise features	Code: an access function that filters by campaign or author
An approver who publishes	Built in: Editor or Administrator publishes; comments and tasks from Growth	Built in: a role that may publish; named review stages are enterprise Publishing Workflows or custom work
Four documents live at 09:00	Plan: Content Releases, an Enterprise add-on; on Growth, one scheduled draft per document	Built in: scheduled publish per document, run by the jobs queue; grouping them into one release is custom work
Rolling back the launch	Plan: rolling back a release is Enterprise-only; any plan can revert a document within its history window of 3, 90 or 365 days	Built in: restore each document from its versions, with retention you configure; a one-step rollback of the set is custom work
Getting the content out later	Built in: NDJSON export and a CLI tarball with assets	Built in: the content is in your database; transforming it for the next system is project work

On Sanity, most of the job is product, and two parts depend on the plan. Growth covers the languages through plugins, the shared call to action as a referenced document, writers who cannot publish, review through comments and tasks, and a launch built from scheduled drafts, one per document, set for the same minute. A strong reference stops a page from being scheduled while the call to action is unpublished, so publish that document first or put everything in one release. Two requirements move the project to Enterprise: writers limited to the campaign pages, which needs custom roles, and one release that launches and reverts as a unit, which is the Content Releases add-on. Sanity also documents Workflows for named review stages; it is in early access, and its early-access notes say “Every check the engine makes is advisory”.

On Payload, most of the job is schema and access code, with no plan gate. Localized fields carry both languages in one document, and the call to action is its own document that the pages point to, with its own draft and publish state. The writers’ rules are access functions: they may update campaign pages, and only as drafts. Payload’s drafts documentation notes that the drafts-only pattern “also blocks scheduled publish jobs from executing for those users”, so the approver sets the launch schedule, and the deployment has to run the jobs queue for it to fire. When per-field rules outgrow hand-written functions, the pattern is the one behind our field-level RBAC plugin. Named review stages are Payload’s enterprise Publishing Workflows or custom work; a grouped release and a one-step rollback are custom work.

If an assistant drafts the German copy, the same approval line has to hold. Sanity’s Content Agent does not publish, and an MCP client working under a Contributor’s permissions cannot publish either. On Payload, the MCP plugin writes the main document unless the call sets draft: true, so the update rule that stops writers publishing has to apply to the assistant’s API key as well. The AI section below covers both routes in detail.

Evidence to collect before choosing. On Sanity, confirm which plan each row lands on, get an Enterprise quote if writers must be restricted or the launch must be one release, and try the Contributor role and scheduled drafts on a trial. On Payload, have the access functions written and reviewed, run a scheduled publish on the target hosting with the jobs queue running, restore a set of documents on a staging copy, and price Publishing Workflows or the build if named stages are required.

Requirements to cost:

• Editors and writers. Sanity charges $15 per seat per month on Growth, up to 50 seats; Payload’s open-source core has no seat fee.
• Writers restricted to part of the content. Sanity: Enterprise custom roles. Payload: build time for access functions.
• One launch for many documents, and one rollback. Sanity: Enterprise, with Content Releases as an add-on. Payload: per-document scheduling and restore, or build time for a release feature.
• Named approval stages. Sanity: Workflows in early access, or custom document actions. Payload: enterprise Publishing Workflows or build time.
• Running the platform. Sanity: included in the subscription. Payload: hosting and operations, by your team, a partner or Payload’s enterprise hosting.

When keeping Sanity is the sensible call

This scenario is illustrative. It is not a client project. A publisher’s content team of twelve editors works on Growth. They co-write long features in the Studio every day, launch pieces one at a time with scheduled drafts, and use Content Agent for audits. There is no requirement to keep content inside their own perimeter, and nobody on staff wants to own a deployment. Staying on Sanity is the sensible call: the Growth bill is published and can be modelled against its quotas, character-level co-editing is a daily need that Payload does not have built in, and nothing on the requirement list needs Enterprise. The picture changes if the team needs writers restricted to part of the content or launches that span many documents, because both move it to Enterprise pricing.

Localising a product update: the same job on each platform

“AI support” on a CMS covers three separate things. An editor-facing agent is a product the vendor runs, driven from the editing interface. MCP connectivity lets an outside assistant read and write your content. Retrieval tooling, such as embeddings and semantic search, is what lets either one find the right documents first; the table above carries a row for each of the three. A platform can ship one of the three and still leave you building the workflow. Our agentic CMS checklist covers the capability questions to ask a vendor; the operation below is costed on both sides.

Take a product update that has to reach two more languages: three documents, translated, reviewed by someone who reads the language, then published. The walkthrough below is built from each vendor’s documentation, first checked on 10 and 11 September 2026 and rechecked on 29 September 2026. We have not run this operation on either platform, so treat it as an illustration of the documented mechanics.

On Sanity, the managed path exists and is metered. An editor opens Content Agent in the Sanity Dashboard or in Slack and asks for the translation; nothing is installed. Sanity’s own cost table puts “translate 3 documents into 2 languages” at roughly 76 credits, about $3.80 at $0.05 a credit, and every plan carries a monthly allowance: 1,000 credits on Free and Growth, 5,000 on Enterprise. Growth buys more at $0.05 each. Free cannot, so AI pauses there until the next calendar month. Bulk work asks for confirmation once the estimate reaches 100 credits. The agent proposes the translated documents, a person confirms them into drafts or a content release, and publishing stays a separate step that the agent cannot take.

A team that wants an outside assistant such as Claude Code or Cursor to do the work connects it to Sanity’s MCP server instead. Its document tools write to drafts or release versions, and the patch tool’s documentation states that published content is never modified directly. Most MCP tools are ordinary API calls that draw no AI credits; generate_image and transform_image are the exceptions.

Publishing and unpublishing are separate tools, publish_documents and unpublish_documents, so an organisation that wants a person to make the final call can leave both out of the client. On Growth and Enterprise, the Contributor role can write but not publish, which enforces the same split through permissions. Access runs on OAuth by default, with sessions that expire after about seven days, or on an API token whose role and permissions bound what the agent can touch. A personal token carries your own permissions and attributes the changes to you in the revision history, which decides whether the trail shows a named person or a service account. Sanity keeps that history for 3, 90 or 365 days depending on the plan, and the full audit trail and History API are Enterprise features.

On Payload, the connectivity ships and the agent is yours. The MCP plugin is open source and runs inside your own deployment at /api/mcp, so no content crosses to a vendor’s AI service unless you send it there. Payload’s open-source product has no editor-facing translation agent to open, which makes this operation a build: you choose a model provider, write the prompt and the review step, and pay that provider directly. The plugin has no credit meter because it does no inference. Payload lists AI translations among its enterprise features, which are sales-led with no published price.

Permissions are deliberately two-stage. Enabling a collection in the plugin config does not expose it; you then create an API key in the admin panel and switch on find, create, update or delete for that key individually. Every request carries the key as a bearer token, and Payload evaluates your existing access-control functions, hooks and multi-tenant rules for the user behind it, so the agent inherits the rules you already wrote. With drafts enabled, Payload stores publication state in a _status field on the document, and an update that sets it to published publishes the document, as the drafts documentation sets out. The plugin’s permissions stop at update, and its create and update tools default to draft: false, so an agent’s edit is written to the main document that standard reads return unless the call asks for a draft. To hold editing and publishing apart, restrict who can set _status to published in the collection’s update access. With drafts on, Payload keeps a version of each saved change, but the core version record stores no user field, so attributing a change to a person is something the build adds. The plugin’s onEvent callback, invoked for every MCP event, is where you would log the MCP calls themselves.

Which way this points. On the managed side Sanity has the product and a price. Content Agent is on every plan, its cost is a published meter you can model against a monthly allowance, and publishing stays with a person. Payload’s counterpart is its enterprise AI translations, which are sales-led with no published price. A team that wants translation working this quarter without engineering time can cost the Sanity route from its pricing page; the Payload route needs a sales quote.

Both platforms also have a build route. On Sanity, the MCP server works with any MCP-compatible client and any model you point at it, and most of its tools draw no credits. Its Agent Actions call Sanity’s own AI and charge 1 credit, $0.05, per request, one document into one language, with the API marked experimental. Sanity’s own guidance names Agent Actions for localisation pipelines, and Agent Actions or asynchronous Content Agent API requests for jobs in the thousands of documents. Payload’s build is the MCP plugin, which carries no licence fee, plus a model provider you choose and pay directly. Over MCP on either platform, the model bill depends on the provider you pick.

Payload keeps the documents in your own database and runs the MCP server inside your deployment. Sanity keeps them in the Content Lake and runs its MCP server at mcp.sanity.io, both on its own infrastructure. On either MCP build, the model provider you pick receives the text it translates, under that provider’s terms. For the managed routes, Sanity’s Content Agent documentation states that conversations “may be stored for up to 30 days to improve the system”, and Payload’s enterprise AI page says content is translated by “your preferred LLM” and states no retention period.

For this operation, Sanity is the stronger answer when the content can sit in a vendor’s cloud. A requirement to keep the documents and the assistant’s traffic inside your own perimeter reverses that. Payload can meet it when the model also runs inside the perimeter. On both Sanity routes the documents live in the Content Lake, which that requirement rules out.

Pricing and total cost of ownership

Sanity’s pricing is public and metered: Free at $0, Growth at $15 per seat with published overage rates on API requests, bandwidth, and assets, and a custom-quoted Enterprise tier that holds most of the governance surface — SSO, custom roles, Content Releases as an add-on, the audit trail, backups. Documents are a hard cap on Free and Growth, with no overage. The bill grows with seats and usage, which makes it easy to start and worth modelling before you scale.

Payload’s open-source core is free to self-host; the cost is the infrastructure it runs on and the work of operating it, including staying current with security patches. That work can sit with your own team, a delivery partner, or Payload, whose get-started page lists hosting and dedicated support among what enterprise customers can unlock. For a small team with light usage, Sanity’s Free plan is hard to beat on cost. At institutional scale — many seats, heavy API traffic, several environments — an owned deployment usually wins, and the predictability of the curve is often worth as much as the number.

Payload Cloud is paused for new projects; existing Cloud projects keep running, according to Payload’s Cloud FAQ. A new Payload project today runs on your own infrastructure, from the Vercel or Cloudflare templates, or on Payload’s enterprise hosting.

Payload’s enterprise gate was checked at the source on 14 September 2026 and again on 29 September 2026: SSO and publishing workflows on Payload’s enterprise page, and the system-wide audit log on its enterprise audit-log page. Payload publishes no price for the tier that carries them.

An earlier long-form version of this comparison stays online as an archive, with the version-stamped pricing tables, governance detail and the full source list: the long-form Sanity vs Payload write-up. This page is the one kept current.

A note on our position

WAYF is a Payload Partner agency and a top contributor to its open source, so we have an interest in this comparison. We pick Payload often because self-hosting, code-first modeling, and no lock-in fit how we and our clients build. When a team is better served by a managed platform, that is the recommendation we give, and Sanity is a strong one.

If you choose Payload, WAYF’s Payload development service covers the build. For a move from an existing CMS, plan the replatforming around the content, infrastructure and editorial controls that need to move.