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 install, run, and own. 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 run yourself. 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. The whole platform is MIT-licensed, and it has stayed that way since Figma acquired Payload in June 2025.

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 with infrastructure and patching on your plate.

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.

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, checked on 10 and 11 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, transform_image and create_version with an instruction 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, the audit trail, backups. The bill grows with seats and usage, which makes it easy to start and worth modelling before you scale.

Payload’s software is free to self-host; the cost is the infrastructure you run it on and the engineering time to operate it, including staying current with security patches. 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, the first-party managed hosting option, is currently paused for new projects. Choosing Payload today means hosting it yourself or on a platform like Vercel or Cloudflare.

Payload’s enterprise gate was checked at the source on 14 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.