Sanity vs Payload: a managed content platform or a backend you own?

The maintained side-by-side version of this comparison, kept current with both platforms, lives at Sanity vs Payload.

Both platforms changed more in the last fifteen months than most comparisons you will find reflect. Payload joined Figma in June 2025 and stayed MIT-licensed, with Payload Cloud since paused for new projects. Sanity raised an $85M Series C in May 2025 and repositioned as “the Content Operating System for the AI era,” then shipped Studio v6 in June 2026. Everything below is checked against the live documentation and pricing pages as of Payload 3.86 and Sanity Studio 6.5, July 2026.

The structural difference comes first, because every other trade-off follows from it. Sanity pairs an open-source editing application (Sanity Studio, MIT) with a managed backend: the Content Lake, hosted by Sanity, which stores your content and cannot be self-hosted. Payload is an MIT-licensed backend in its entirety: it installs into a Next.js application, runs on a database you choose and operate, and is free to self-host. Choosing between them is choosing an operating model, and only then a feature set.

How they are fundamentally different

• Sanity’s model is a platform you subscribe to. The Studio is open source and self-hostable as a static single-page app, and it connects to Sanity’s hosted APIs and Content Lake. Sanity’s own FAQ states it plainly: “the Content Lake where data is stored must be hosted by Sanity.” You get a fully managed, real-time content database on Google Cloud with zero database operations on your side, and you pay per seat and per usage as you grow.
• Payload’s model is a framework you own. The whole product is MIT-licensed, installs into a new or existing Next.js app, and officially supports three databases: MongoDB with Mongoose, Postgres with Drizzle, and SQLite with Drizzle. Payload’s own words: “Deploy it anywhere you can run a Node.js app — for free, forever.” The infrastructure, and the responsibility for it, are yours.

Neither model is the safe default. A managed platform takes operations off your plate at the cost of control; owning the backend gives you the control along with the operational load. The rest of this comparison is that trade playing out surface by surface.

Head-to-head: the deciding factors

Architecture and hosting

Sanity’s Content Lake is a fully managed database on Google Cloud Platform. Sanity’s security page states its backend systems run “across three data centers in a single EU region (Belgium),” with customer content stored “in the EU/EEA, the US, or in regions where Sanity has an operational footprint, specific by customer.” Real-time infrastructure, CDN delivery, and scaling are Sanity’s problem. Sanity is SOC 2 Type 2 certified, which matters to procurement checklists that require a certified vendor.

Payload deploys “anywhere that Next.js can run — including Vercel, Netlify, SST, DigitalOcean, AWS, and more,” per its deployment docs, which also note that most projects will need their own database, file storage, email provider, and CDN. Data residency is wherever you deploy, which for regulated organisations can be the entire argument: the platform runs inside your infrastructure and your compliance perimeter. Payload’s security page documents engineering practices (HttpOnly cookie auth, CSRF prevention, field-level access control) and lists no third-party certifications; a self-hosted deployment inherits your organisation’s own compliance posture rather than a vendor’s.

Self-hosting also means patching. In February 2026 Payload disclosed a critical SQL injection vulnerability in its Postgres/SQLite adapters (CVSS 9.8, patched in 3.73.0). Managed platforms patch the data plane for you; owned platforms make the patch schedule your job. Both facts belong in the decision.

Pricing and the cost model

Sanity’s pricing is public and metered, and the Free plan is genuinely generous for small teams: $0 with 20 seats, 10k documents, 1M CDN requests and 100GB of bandwidth per month. Growth is $15 per seat per month with up to 50 seats and 25k documents; Enterprise is a custom quote. On Growth, published overage rates apply beyond the quotas: $1 per 25k API requests, $1 per 250k CDN requests, $0.30 per GB of bandwidth, and $0.50 per GB of assets. Two add-ons extend the plan further: an increased quota raising the document ceiling to 50k in total at $299 per month, and additional datasets at $999 per dataset per month. Dedicated support is a $799 per month add-on. The Enterprise gate holds most of the governance surface: SSO, custom roles, Content Releases, the audit trail and History API, and backups.

Payload publishes no pricing, because the core is not priced: the software is MIT and self-hosting is free. The total cost is not zero, and Payload’s own deployment docs are candid about why: you provision and run the database, file storage, email, and CDN, and your team’s time operates all of it. Enterprise features (SSO via SAML/OAuth, publishing workflows, audit logs, AI features) are sold through a sales-led enterprise engagement with no published price list.

One current fact changes the managed-hosting calculus: Payload Cloud is paused for new projects. The live FAQ states “deployment of new projects is currently paused, existing Cloud projects will continue running as normal,” and existing customers are told they will eventually need to migrate, with Payload “planning to build something better that you will be able to migrate to once it’s available.” If you want Payload today, plan to host it yourself or on a platform like Vercel or Cloudflare; a first-party managed option is not currently on the table.

The cost shapes differ more than the amounts: Sanity’s bill grows with seats and usage, while Payload’s grows with the infrastructure and engineering time you commit. Which curve is steeper depends entirely on your organisation, and any comparison that gives you a universal crossover number is guessing.

Developer experience

Both platforms define schemas in code, in version control, reviewable in pull requests. Sanity schemas are code in the Studio configuration, written in JavaScript or TypeScript; Payload schemas are TypeScript in payload.config.ts and the files it imports.

The query layers differ. Sanity’s primary language is GROQ, an openly specified query language (the spec lives at spec.groq.dev) whose strength is expressive single-query projections and joins across documents; Sanity’s own docs recommend it over their GraphQL API. The generated GraphQL API exists with documented limits: no mutations (writes go through the separate Mutation API) and no cross-dataset references. A typical fetch:

// Sanity: GROQ via @sanity/client
const posts = await client.fetch(
  `*[_type == "post" && published == true]{ title, slug }`
)

Payload’s standout is the Local API: because Payload runs inside the Next.js application, Server Components query the database as direct function calls, with no HTTP hop and no API tokens in the path:

// Payload Local API in a Next.js Server Component
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPage() {
  const payload = await getPayload({ config })
  const posts = await payload.find({
    collection: 'posts',
    where: { published: { equals: true } },
  })
  return <PostList posts={posts.docs} />
}

Payload also exposes REST and GraphQL for any other frontend. The honest caveat is the coupling: Payload today is a Next.js framework, and teams on other stacks consume it as a conventional headless API without the Local API advantage. Payload’s announced 4.0 aims at exactly this with a framework adapter pattern so teams “will be able to choose the framework that best fits their project.” 4.0 has not shipped, though: as of July 2026 it exists only as canary builds, with Payload targeting a beta within the next quarter per the official June 2026 post. Evaluate on 3.x, and treat 4.0 as roadmap.

Editorial experience

This is Sanity’s strongest ground. The Studio is built for real-time collaboration: “Same document, multiple editors, character-level sync. No locking, no merge conflicts, no ‘someone else is editing this,’” per Sanity’s own product page, and any field can be replaced with a custom React component. Visual editing is included on every plan, Free included. Canvas adds AI-assisted free-form writing that maps back into structured Studio documents. Comments, tasks, and scheduled drafts arrive on the Growth plan; Content Releases, which group multiple document changes into a previewable, schedulable unit, are Enterprise-only. Draft and version history retention is plan-tiered: 3 days on Free, 90 on Growth, 365 on Enterprise.

Payload’s admin panel is generated from your config, lives at /admin inside your app, and is customisable with React down to individual fields and views. Live Preview renders your actual frontend inside the panel and updates as editors type. Versions, drafts, and autosave are core features, opt-in per collection, with retention you configure yourself (the default keeps 100 versions per document; zero means keep everything). Scheduled publishing is built in, with one operational string attached: it runs on Payload’s jobs queue, which your deployment has to be processing.

The pattern repeats: Sanity ships more editorial workflow as finished product, tiered by plan; Payload ships the primitives in core, unmetered, and expects your team to assemble the workflow.

Roles, access control, and governance

The two systems are genuinely different here, and the difference is often decisive for institutions.

Sanity ships roles as a product feature, tiered by plan: two predefined roles on Free (Administrator, Viewer), five on Growth, and custom roles on Enterprise only. Enterprise custom roles do content-level access control through GROQ-filtered content resources and user attributes; permissions are additive. The documented model governs access at the content and document level; field-level permissions are not part of the documented roles system.

Payload has no built-in role system. Its access control is code: functions at the collection, global, and field level, scoped per operation, executed before anything changes. Roles are a pattern you implement in those functions (the docs’ own examples check a role field), or adopt from the community. That makes Payload’s access control more granular — genuinely field-level — and simultaneously more work: nothing exists until your team writes or installs it. We know this trade-off first-hand, having built a field-level RBAC plugin for Payload for a multi-tenant enterprise platform when the pattern outgrew hand-written functions.

For the broader question of what governance institutions actually need from a headless build — roles, workflow, audit, and where each should live — we’ve written a separate piece on content governance.

AI capabilities

Both companies are betting on AI; the maturity differs. Sanity’s is shipped and platform-wide: Content Agent runs content operations from natural language (“Show me all product pages missing meta descriptions”), performs audits and bulk edits, stages changes for human review, and is available in the Dashboard, Slack, and via API. Sanity hosts an MCP server at mcp.sanity.io that lets AI clients query and patch content schema-aware. AI is included on every plan through a credit system: 1,000 credits per month on Free and Growth, $0.05 per credit beyond, with a Content Agent query costing 4 credits; most MCP-server tools are ordinary API calls and consume no credits at all.

Payload’s MCP support exists today as an official plugin, with per-collection allow/deny controls over find, create, update, and delete, plus custom tools. The 4.0 announcement sets the goal of making MCP work nearly out of the box, and the enterprise tier lists AI features including auto-embedding for retrieval use cases. As of July 2026, Sanity’s AI surface is the more finished of the two.

Localization

Payload’s localization is core and field-level: set localized: true on a field, configure your locales, and the docs state there are no limits on how many you add. Sanity has no native locale manager; the docs describe two schema patterns — field-level and document-level translation — implemented through official plugins, with AI Assist available for translations. Both approaches ship real multilingual sites; the difference is where the configuration lives.

Lock-in and exit

Exit paths deserve more attention than they get in most comparisons, so here they are, symmetrically.

Leaving Sanity: a full export exists and is not plan-gated. The export API returns every non-deleted document, including drafts, as an NDJSON stream, and the CLI produces a tarball including binary assets. Your rich text comes out as Portable Text, an open, MIT-licensed specification that still requires conversion into whatever your next system uses. GROQ queries are rewritten on exit, and the Content Lake itself stays behind, because it only exists as Sanity’s hosted service. Note that managed backups (365-day retention) are an Enterprise feature; export is the exit door on every plan.

Leaving Payload: your content is already in a Postgres, MongoDB, or SQLite database that you run, so there is no export step and no vendor door to walk through; the migration work is rewriting the application layer. The symmetric caveat: Payload’s default rich text editor is Lexical, and Lexical’s JSON needs conversion if you move to a system that doesn’t speak it, exactly as Portable Text does.

Both platforms are better than average here. The difference is that Payload’s exit is a property of the architecture, and Sanity’s is a property of the vendor’s documented export path.

The comparison table

	Sanity (July 2026)	Payload 3.x (July 2026)
What’s open source	Studio (MIT); Content Lake is hosted-only	Entire product (MIT)
Hosting	Managed (GCP); Studio self-hostable	Self-hosted anywhere Next.js runs; Payload Cloud paused for new projects
Database	Content Lake (Sanity-hosted)	Your choice: Postgres, MongoDB, SQLite
Pricing model	$0 Free / $15 per seat Growth / Enterprise custom, plus usage overages	Free to self-host; sales-led enterprise tier
Enterprise gates	SSO, custom roles, Content Releases, audit trail, backups	SSO, publishing workflows, audit logs, AI features
Roles	Predefined per plan; custom roles Enterprise-only	None built in; function-based access control, roles via your code or plugins
Field-level access control	Not in the documented roles model	Core (field-level access functions)
Real-time co-editing	Core Studio capability, character-level	Not built in
Visual/live preview	Visual editing on all plans	Live Preview built in
Rich text format	Portable Text (open spec)	Lexical (JSON)
Version retention	3 / 90 / 365 days by plan	Configurable, default 100 versions per document
Scheduling	Scheduled drafts (Growth+), Content Releases (Enterprise)	Built-in, runs on the jobs queue
Localization	Via official plugins, two patterns	Core, field-level, unlimited locales
AI	Content Agent + hosted MCP server, credit-metered on all plans	Official MCP plugin; more promised in 4.0
Compliance certifications	SOC 2 Type 2	None listed; inherits your infrastructure’s posture
Exit path	Full NDJSON + assets export on every plan; Portable Text conversion	Your database, no export step; Lexical conversion
Current version	Studio 6.5 (v6 shipped June 2026)	3.86; 4.0 announced, pre-beta

GitHub and npm numbers exist but compare poorly: Payload’s repo (about 43.7k stars) is the entire product, while Sanity’s repo (about 6.2k stars) is only the open-source Studio, and npm weekly downloads lean the other way (sanity about 878k, payload about 560k for mid-July 2026) while counting different layers of each stack. Plugin ecosystems are healthier than either number suggests: Sanity’s directory lists 302 tools and plugins (43 official), and Payload lists 11 official plugins with 236 community repos under GitHub’s payload-plugin topic. Treat popularity metrics as trivia; both projects shipped stable releases in the two weeks before this article was published.

When Sanity wins

Sanity is the right choice when:

There is no infrastructure team, and there should not be one. The Content Lake removes database operations, scaling, and data-plane patching entirely. For marketing-led organisations without engineering ownership of infrastructure, that is the whole decision.

Real-time collaborative editing is core to the workflow. Character-level multiplayer editing in the Studio is a shipped, mature capability that Payload does not have built in. Newsrooms and large content teams working in the same documents simultaneously will feel this daily.

The AI content-operations story matters now. Content Agent doing audits, bulk edits, and natural-language operations across a large corpus is shipped and usable today, on every plan, with predictable credit pricing.

A small content team wants a serious free start. Twenty seats, high quotas, and zero infrastructure on the Free plan can be the entire evaluation for an early-stage team.

A certified managed vendor is a procurement requirement. SOC 2 Type 2 on the vendor side satisfies checklists that a self-hosted deployment satisfies differently (through your own infrastructure’s compliance), and some procurement processes only accept the former.

When Payload wins

Payload is the right choice when:

The team is TypeScript and Next.js native. One codebase, one deployment, the Local API instead of a network boundary, and generated types end to end. This remains the sharpest single advantage either platform holds over the other.

Content must live in your infrastructure. Regulated industries, public institutions, and data-residency requirements are served structurally: the entire platform, database included, runs inside your perimeter. Sanity can arrange content regions per customer; Payload removes the vendor from the data path altogether.

Cost needs to be predictable at institutional scale. Payload’s core carries no seat fees, API-request meters, or per-dataset add-ons; you pay for infrastructure and the team you already have. At small scale this can cost more than a free Sanity plan, and at institutional scale the predictability usually wins.

Access control has compliance implications. Function-based, field-level access control that ships through code review offers a different kind of precision than Sanity’s role system, whose custom, content-level roles arrive only on Enterprise. When the auditor asks who can edit what, the answer is a readable function in version control.

The editorial experience should be part of the product. The admin panel lives inside your application and deployment, built from your own React components. Sanity’s Studio is also deeply customisable; the difference is that Payload’s admin ships inside the same codebase and release process as the product.

What the 2025–26 shake-ups mean for a buyer

Payload’s acquisition by Figma (June 2025) came with explicit commitments: “Payload will remain an open-source product” and continued investment in the open-source project. Thirteen months on, the observable record matches: the MIT license is intact, releases have stayed frequent through summer 2026, and 4.0 development is public. The one concrete post-acquisition change a buyer feels is Payload Cloud’s pause, which removes the first-party managed option for new projects.

Sanity’s $85M raise funded a genuine strategy shift: from headless CMS to a platform of connected products (Studio, Canvas, Content Agent, Media Library, App SDK, Functions) under the Content Operating System banner. For buyers that means more capability arriving on the platform, and more of the stack living on Sanity’s side of the line.

Neither company shows distress signals; the risks are simply different in kind. With Sanity you carry vendor-roadmap and pricing-evolution risk on a platform you rent. With Payload you carry the operational responsibility for a platform you own, under an owner (Figma) whose commitments are so far holding.

FAQ

1. Can I self-host Sanity?

   Partially. Sanity Studio is an open-source React single-page app you can host anywhere that serves static files. The Content Lake, where your content actually lives, cannot be self-hosted on any plan: Sanity's own FAQ states "the Content Lake where data is stored must be hosted by Sanity." If full self-hosting is a requirement, Sanity is structurally excluded and Payload qualifies.

2. Is Payload really free?

   The software is: MIT-licensed, with unlimited editors and no metered quotas, and Payload's own site says "for free, forever." The deployment is not: you run a database, file storage, email delivery, and a CDN, and your team operates and patches all of it. Enterprise features (SSO, publishing workflows, audit logs) are paid through a sales-led engagement. Budget Payload as infrastructure plus engineering time rather than as a subscription.

3. Is Payload 4.0 released?

   No. As of July 2026, Payload 4.0 exists as canary builds only; the official June 2026 announcement targets a beta "within the next quarter." The announced scope includes an admin UI redesign, a framework adapter pattern to loosen the Next.js coupling, and simpler MCP setup. Evaluate Payload on the current 3.x line and treat 4.0 features as roadmap until they ship.

4. What happened to Payload Cloud?

   Following the Figma acquisition, Payload Cloud is paused for new projects. The official FAQ states that existing Cloud projects continue running as normal and that customers will eventually need to migrate, with Payload "planning to build something better that you will be able to migrate to once it's available." New Payload projects today deploy to your own infrastructure or platforms like Vercel and Cloudflare.

5. Does Sanity or Payload have better roles and permissions?

   They solve it differently. Sanity ships predefined roles tiered by plan (two on Free, five on Growth) with custom, content-level roles on Enterprise only. Payload has no built-in roles; its access control is functions at the collection, global, and field level, and your team implements roles as code or adopts a plugin. Sanity's presets cover standard editorial teams with no build work; Payload's function-based model reaches individual fields, which compliance-heavy platforms usually need.

6. Which is more popular, Sanity or Payload?

   The honest answer is that the public numbers do not compare cleanly. Payload's GitHub repo holds about 43.7k stars but covers the entire product; Sanity's repo holds about 6.2k stars but covers only the open-source Studio, with the platform itself available only as Sanity's hosted service. npm weekly downloads lean toward Sanity (about 878k vs 560k in mid-July 2026) while similarly counting different layers of each stack. Both projects shipped stable releases in July 2026. Base the decision on the operating model, not the star counts.

7. Can I migrate from Sanity to Payload?

   Yes, and the export side is well supported: Sanity's export API returns all documents including drafts as NDJSON, and the CLI export includes binary assets, on every plan. The substantive work is on the import side: mapping Sanity schemas to Payload collections, converting Portable Text rich content to Lexical, resolving references, and rebuilding queries from GROQ to Payload's APIs. The same is true in reverse. It is a real project with a well-defined shape, comparable to the CMS migrations we document elsewhere on this blog.

Disclosure: WAYF is an official Payload partner and top contributor, so we know that side of this comparison best. We build content platforms and CMS migrations on Payload and Next.js. If you are weighing Sanity against Payload for a specific project and want a second opinion, book a call or see our work.

Sources

• Sanity, pricing and plan quotas
• Sanity, frequently asked questions (Content Lake hosting)
• Sanity, Studio deployment docs
• Sanity, roles documentation
• Sanity, data export HTTP reference
• Sanity, security and compliance
• Sanity, Studio v6 release post
• Sanity, Content Agent documentation
• Payload CMS, what is Payload
• Payload CMS, database overview (supported adapters)
• Payload CMS, access control overview
• Payload CMS, deployment docs
• Payload CMS, Payload 4.0 announcement
• Payload CMS, Payload Cloud update FAQ
• Payload CMS, Payload is joining Figma
• Payload CMS, security practices
• Payload CMS, security advisory GHSA-xx6w-jxg9-2wh8 (SQL injection, patched in 3.73.0)
• Sanity, the end of the CMS era and the $85M Series C
• Sanity, Studio product page (real-time collaboration)
• Portable Text specification