Sanity or Payload: which fits your team's content and operating model
Choose Sanity if your team wants managed real-time collaboration and hosted content storage, and choose Payload if the CMS should live inside your own Next.js app and your own database. The decision turns on three questions: where content must physically reside, how much operating work your team will take on, and how much weight you give Sanity's hosted features. A renewal or a residency review is usually the trigger, but the answers to those three questions should drive the choice. Start with residency and exit. Sanity Studio is MIT licensed and can be deployed on your own infrastructure, but the content itself stays in Content Lake, which Sanity hosts. If your auditors or data owners require content to sit in a database you control, Payload is the closer fit, since it runs on self-hosted MongoDB, PostgreSQL or SQLite. Confirm with your data protection and security owners which data classes must stay in-house, including draft content, version history and uploaded assets, before you compare anything else.
Then weigh the operating work. With Payload, your team owns the Next.js application, the database, backups, upgrades, object storage for assets and the hosting of the admin panel and APIs. Sanity hands most of that to the vendor, and in exchange you accept its collaboration model and hosted history. Ask Sanity for written details of real-time collaboration behavior, history retention by plan and the export options that apply to your contract, and compare them with the restore, backup and upgrade procedures your own team could sustain. If Sanity's hosted collaboration is central to your editors' workflow, price that loss honestly before you decide, and review the Sanity dataset export documentation to confirm what a full export contains.
Which option fits which scenario
This table matches common team situations to the platform that fits them better. Read each row's condition first, because the better fit depends on where content must live, who runs the infrastructure and how much history you need to prove.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Hosted real-time editing with minimal ops | Sanity | Your team wants Sanity to run the Content Lake, real-time collaboration and dataset storage, and accepts a hosted vendor as the content system of record. |
| Content must stay in your own database | Payload | Residency, contract or exit rules require the content tables to sit in PostgreSQL or MongoDB that you operate. Sanity keeps content in its hosted Content Lake. |
| Next.js team wants the CMS in the same codebase | Payload | Your front end is already a Next.js app and you want collections, access control and the admin panel in the same repository and deployment pipeline. |
| Heavy history or audit needs | Depends on plan and configuration | Confirm with Sanity how much document history your plan retains, and design Payload's versions and drafts and your database backups to meet the same retention period. |
| Schema defined in code, editors need a hosted studio | Sanity | Editors work in a hosted, real-time Studio and your developers accept that content reads and writes go through Sanity's APIs. |
| Team expects to own upgrades and hosting | Payload | You can staff the database, object storage, the Next.js hosting and version upgrades, and you want no seat-based vendor dependency for the content layer. |
| Small team without platform engineering | Sanity | No one can own backups, database tuning and Next.js hosting, so the hosted service's operations are worth the lock-in trade-off. |
What the MIT license covers in each product
Sanity Studio is MIT licensed, but that license covers the editing interface only. Sanity's GitHub repository describes Studio as the editing interface and places content in Content Lake, a real-time data store that Sanity hosts. Deploying the Studio on your own hosting therefore changes where the React application runs, not where documents, drafts and history are stored. Before you plan an exit or a residency review, confirm with Sanity which parts of the dataset, including real-time collaboration state and asset storage, would have to move, and treat any self-hosted Studio as a front end to the hosted Content Lake until that is settled. For a wider look at this distinction, see the page on self-hosting Sanity.
Payload is MIT licensed and keeps content in a database you operate. The Payload repository lists MongoDB, PostgreSQL and SQLite as supported databases, so the data layer sits in your own infrastructure rather than in a vendor's store. The license also means no per-seat or per-request fee applies to the software itself. Your team will own the database backups, the object storage for uploads, the hosting of the Next.js application, and the upgrade work. Confirm which database engine your security team will approve, because that choice determines your backup, restore and access control procedures.
Payload v3.91.0 is the current stable line, and v4.0.0 is still in beta. Payload's GitHub releases show v3.91.0 released on October 15, 2026, and v4.0.0-beta.2 published on October 16, 2026. A beta is not a production commitment, so plan a v3 deployment with a documented path to v4 rather than building on pre-release APIs. Before you commit to either line, check the release notes for breaking changes, confirm the migration guidance for your database and custom components, and set a review date to decide when to move.
Where your content and identity live under each option
Sanity and Payload differ most in where content, user accounts and operating responsibility sit. The cards below cover the storage location, hosting choices, identity, compliance evidence and vendor dependency that follow from that difference.
Content location and storage
Sanity Studio is MIT licensed, but content lives in Content Lake, a real-time data store hosted by Sanity. Running the Studio on your own servers does not move the documents. With Payload, documents sit in a database you choose, either MongoDB or PostgreSQL, in an account you control. Ask Sanity which region hosts your datasets and confirm whether that region meets your residency rules before you commit to a schema.
Hosting choices for Payload
Payload is a Next.js native CMS that installs into an existing /app folder, so the admin panel and API run in the same application. It can deploy to Vercel, to Cloudflare Workers with R2 and D1, or be self-hosted anywhere. Each target sets different limits on database connections, file storage and logging, so test your chosen path against your own traffic and backup requirements before you pick one.
Built-in identity for admin and customers
Payload includes authentication, so admin users and customer users can be managed inside the CMS itself. Sanity handles Studio access through its own project membership, and customer identity for an application usually sits in a separate provider. With Payload, you decide whether to keep customer accounts in the CMS or federate them to an identity provider, and you must define password policy, session lifetime, MFA and offboarding in your own configuration.
Residency, audit and evidence
With Content Lake, your audit evidence depends partly on Sanity's controls and reports, which you must request and review. With Payload, you produce the logs, database backups, access reviews and change records yourself. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications. Confirm the compliance scope and the evidence formats your auditor expects before you choose the architecture.
Dependency on Sanity's uptime and roadmap
Under Sanity, your editing workflow, content API and history depend on a hosted service and on Sanity's roadmap and pricing decisions. Under Payload, availability depends on your database, hosting and deployment process, and upgrades follow the releases you adopt. Payload's v3.91.0 release is dated October 15, 2026, and a v4.0.0 beta line is in progress, so plan upgrade testing as ongoing work rather than a one-time event.
How hosting choices change the operating work
With Sanity's hosted model, Sanity operates Content Lake, the real-time data store where your documents and assets live. Your team does not patch the database, size its storage or manage its replicas. What remains with you is the front end that reads content, the schema code in your Studio project and the dataset configuration. Studio itself is MIT licensed, so you can deploy it on your own hosting, but the content it edits still sits in Content Lake.
- Patching: Sanity maintains the hosted data store. Your team upgrades the Studio package and the front-end framework.
- Backups: Your team runs the
sanity dataset exportcommand to take a copy of a dataset, including document history and asset files. Ask Sanity which backup and retention guarantees apply to the hosted service itself. - Scaling: Content Lake capacity and API limits are set by your Sanity plan. Scaling the read path depends on your front-end host and CDN.
- Monitoring: You monitor your front end and Studio deployment. Confirm which service status and usage signals Sanity exposes to you.
Before you rely on this model, confirm where Sanity hosts Content Lake for your plan, which data residency options apply and what an export costs you in time when you need to leave.
Teams sometimes host the Sanity Studio on their own cloud account or a static host while keeping content in Content Lake. This changes who controls the editing interface and its build pipeline, but it does not move the content. Studio is a React application that is built and deployed like any other front end, so the operating work is mostly the build, the dependency updates and the access controls at the Studio URL.
- Patching: Your team updates Studio and its dependencies, then rebuilds and redeploys.
- Backups: Studio holds no content of its own, so back up the project code and its configuration in Git. Content backup still depends on exports from Content Lake.
- Scaling: Studio traffic is limited to editors, so a small static host usually suffices. Read traffic to the published site is served by your front end.
- Monitoring: Track Studio build failures and login issues. Content availability still depends on Sanity.
The main choice here is operational control of the editing layer, not data residency. Ask your team which environments need separate Studio deployments and who approves changes to the schema code.
Payload installs into a Next.js /app folder and supports self-hosted MongoDB, PostgreSQL and SQLite databases, so you can run the application and database on virtual machines in your own cloud account or data center. Your team owns every layer, from the operating system and database engine to the application process and the TLS certificates. This gives full control over data location and network paths, and it also places every recurring task on your team.
- Patching: You patch the operating system, runtime, database and Payload packages on a schedule you set.
- Backups: You configure database backups and object storage for uploads, then test restores. Payload does not replace this duty.
- Scaling: You size instances and add nodes by hand or with an autoscaling group, and you manage connection pooling.
- Monitoring: You run logging, metrics and alerting for the app and database, and own the on-call response.
Ask your platform team to estimate these duties against its current skills. Confirm the supported database versions for your Payload release in the Payload repository before you choose an image.
Running Payload in containers on Kubernetes or a container platform moves much of the process work into standard tooling. Your team still owns the images, the database and the upload storage. Container orchestration handles restarts, rolling updates and horizontal scaling, but it does not decide how your database is backed up or how your secrets are rotated.
- Patching: You rebuild images when Payload or base images change, then roll them out through your pipeline.
- Backups: The database remains outside the container lifecycle. Use a managed or operator-run PostgreSQL with point-in-time recovery, and test restores on a schedule.
- Scaling: Horizontal scaling depends on how many instances share the database and the job queue. Test the load profile before you set limits.
- Monitoring: Collect container and application metrics, plus database health, in your existing observability stack.
Check how your platform team plans to handle secret rotation for the Payload secret and database credentials. Confirm the upgrade path against the release notes in the Payload GitHub releases page before each version change.
Payload can deploy to Vercel or to Cloudflare Workers with R2 and D1, or be self-hosted anywhere. Serverless targets remove most server patching and scaling decisions, but they add constraints on database connections, file handling and runtime limits. The operating work shifts toward the provider account, the database binding and the build pipeline. Confirm the platform's exact limits for your workload with the provider.
- Patching: The platform handles the runtime. You still update Payload and its dependencies, and you rebuild on each change.
- Backups: The database and object storage are separate services. Confirm their backup and restore options and test a restore.
- Scaling: The platform scales requests automatically, but database connection limits can become the bottleneck. Review this with your database choice.
- Monitoring: Use the provider's logs plus application-level monitoring. Confirm retention periods with the provider.
For regulated data, confirm where the serverless platform processes requests and stores logs, and whether that matches your residency rules. Ask your team to document these answers before selecting a target.
What drives the cost of each option
Sanity and Payload charge for different things, so the cost comparison starts by sorting each line item into one-time or recurring. Hosted Sanity bundles most infrastructure into its plan terms, while self-hosted Payload moves that work to your invoices and your team. Check each item against current terms and your own environment before comparing totals.
Sanity seats, documents and requests
Sanity's plan terms set the recurring charges, which can include seats, document and API request allowances, and add-ons such as extra capacity or features. Editor headcount and content growth are the usual drivers, so model them for the next several years, not only today. Ask Sanity in writing which limits apply to your plan, what happens when you exceed them, and how overage is billed.
Database and backups for Payload
Payload runs on MongoDB, PostgreSQL or SQLite, so you pay for a managed or self-run database, its storage, replicas and backups. Content volume, version and draft history, and the number of locales all grow the database. Confirm who owns backup testing and restore drills, because those tasks are easy to leave out of a self-hosted estimate.
Object storage, CDN and app hosting
Assets, images and rendered pages add recurring costs for object storage, bandwidth through a CDN and compute for the Next.js application. Traffic patterns and image sizes drive these costs more than content volume. Payload can deploy to Vercel, to Cloudflare Workers with R2 and D1, or on your own servers, and each option prices these components differently, so ask for a line-by-line estimate.
Upgrades and engineering time
Self-hosting shifts version upgrades, security patches, dependency changes and CI pipelines onto your engineers. This is a recurring labor cost that rarely appears on an invoice, and it grows with the number of custom fields, hooks and access rules. Sanity's hosted Studio and Content Lake move that work to the vendor, so count the internal hours or a support retainer as part of the Payload total.
Support and incident response
Sanity includes vendor support according to its plan, while Payload's community support is free but has no response commitment. Paid support, a retainer or an internal on-call rota adds a recurring cost. Ask what response times each option commits to, who is paged at night, and what is excluded from the support scope.
One-time migration effort
Moving from Sanity to Payload is largely a one-time cost: rewriting Studio schemas as Payload collections, converting Portable Text to Lexical, loading the export and re-uploading assets. Effort rises with the number of document types, custom Studio plugins and references between documents. Ask for a fixed-scope quote that lists each content type and the test and cutover steps, and check whether an overlap period with both systems running is included.
What moving from Sanity to Payload involves
The sequence turns a hosted Sanity dataset into a Payload application on your own database, with content, assets and drafts checked at each stage. The work is done by your engineers or an implementation partner, and it finishes when editors can work in Payload against content that matches the source.
Export the dataset and inventory the assets
Run the
sanity dataset exportcommand to produce a gzipped tarball that includes documents, document history and asset files. Note any assets the export skips because they return 401, 403 or 404 responses, since those files must be recovered from their original sources. Confirm the tarball opens and that the document count and asset list match what editors see in Studio. The step is complete when you have a dated export and a written list of missing assets.Map Studio schemas to Payload collections
Read the Studio schema files in your Sanity project and translate each document type into a Payload collection or global with equivalent fields, references, validation and access rules. Payload's fields are defined in TypeScript, so this review also confirms which custom input components your editors rely on. Your team should record each mapping in a table that lists every Sanity type and its Payload counterpart. The step is complete when every document type has a reviewed target.
Convert Portable Text to Lexical
Portable Text is Sanity's rich text format, and Payload uses the Lexical editor, so the stored structures need a conversion script. Test the script on a sample of articles that include links, inline references, custom blocks and embedded images, because these are where conversions usually fail. Editors should review the output in the Payload admin panel before any bulk run. The step is complete when the sample renders the same way in both systems.
Load documents and assets into Payload
Write an import job that reads the NDJSON documents from the export, creates Payload entries through its local API, and resolves references between them in a defined order. Upload the asset files to your chosen object storage, then rewrite asset references to point at the new location. Run the import against a staging database first, and keep the import log so failed records can be retried. The step is complete when record counts match the export and every reference resolves.
Rebuild front-end queries and delivery
Replace each GROQ query in your front end with Payload's REST or local API calls, and move any Sanity image URL transforms to the image handling you choose. Check how preview and draft content are fetched, because the preview flow differs between the two systems. Your developers should confirm that cached pages and webhooks still trigger rebuilds after publishing. The step is complete when every template renders from Payload data in a staging environment.
Validate drafts, versions and history
Compare the exported document history with what Payload stores as versions and drafts, and decide which history must be kept for audit or editorial reasons. Ask editors to publish, unpublish and revert a set of test documents, and confirm that the outcomes match expectations. Check that field-level access control and user roles match the permissions your editors had in Sanity. The step is complete when signed-off test cases pass and the history decisions are documented.
Cut over and retire the hosted dataset
Freeze editing in Sanity for the cutover window, run a final export and import, and point production traffic to the Payload deployment. Keep the Sanity dataset read-only for a period you agree with stakeholders so that any gaps can be checked against it. Confirm with Sanity how your plan handles dataset retention and removal before you delete anything. The step is complete when production serves from Payload and the retirement plan is recorded.
Questions buyers ask before choosing Sanity or Payload
Does self-hosting Sanity Studio move my content off Sanity's servers?
No. Sanity Studio is MIT licensed and can be deployed on your own infrastructure, but the content itself is stored in Content Lake, the real-time data store Sanity hosts. Self-hosting the Studio changes where the editing interface runs, not where documents, history and assets live. If residency or exit requirements apply to the content, you need a different data store, which is the main reason teams move to Payload or Strapi. Confirm this boundary with Sanity's current terms and your own data classification before you rely on it.
How long does a migration from Sanity to Payload take?
No duration can be stated here without knowing your data. The main drivers are the number of document types and their references, how much Portable Text needs converting to Lexical, the volume of assets to re-upload, whether draft and version history must be kept, and how many editors need to be trained on the new admin panel. A small schema with few assets is a different project from a large multi-locale site with years of history. Ask any implementation partner for a written scope that lists each of these drivers and the deliverables before agreeing to a timeline.
What does the Sanity export include, and what do I have to rebuild?
The sanity dataset export command writes a local gzipped tarball that includes document history and asset files, but it skips any asset that returns a 401, 403 or 404 response, so those files need a separate recovery pass. Schemas written in Studio code are not the same as Payload collections, so they must be rewritten by hand. Plan for the gaps: broken asset references, Portable Text blocks that need conversion, and any custom Studio plugins or input components that have no direct equivalent. Check the export manifest against your asset count before you decommission anything.
Can an in-house team run Payload after the migration?
Often yes, if the team already runs TypeScript and Next.js applications. Payload installs into an existing Next.js /app folder, generates TypeScript types from its collections and fields, and supports self-hosted MongoDB, PostgreSQL and SQLite databases. Your team will own the database, backups, upgrades, the hosting of the Next.js app and access control rules. If nobody on the team has operated a production database or a Node.js service before, the operating work is the part to assess honestly, and a retainer or a training plan may be worth pricing alongside the build.
What skills does a Next.js team need to run Payload well?
The team needs working knowledge of Next.js, React, TypeScript and the database you choose. Payload's features, including versions and drafts, localization, field-level access control, document and field hooks and live preview, are configured in code, so developers will write and review those changes. Editors will use the React admin panel, which can be customized. Hosting options range from Vercel and Cloudflare Workers with R2 and D1 to any self-hosted server, and each brings its own skills. Confirm which deployment target your security team has approved before the design is finalized.
How should I handle assets and document history during the move?
Export first, then verify. Keep the full tarball as a retained copy, compare the asset files it contains against the asset references in your documents, and re-upload any gaps from the original source where you still have access. For history, decide early which revisions must survive the move, since Payload's versions and drafts are configured per collection and may not map one to one with Sanity's document history. Record the decision and the mapping in writing, because auditors and content owners will ask how past content was preserved.
When should we bring in outside help for this move?
Bring in outside help when the scope includes data residency requirements, many document types with complex references, a large asset library, or a deadline that your team cannot absorb alongside its normal work. DeployOpen plans, implements, customizes, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts or data centers. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so ask for a quote based on a written scope.
How DeployOpen helps you decide and implement
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Sanity to Payload decision, that starts with an evaluation against your current requirements rather than a generic recommendation. The questions we would work through with your team are concrete: which Studio schemas and custom input components need to become Payload collections and fields, whether your editors depend on real-time collaboration in the way Sanity provides it, how many years of version history your content policy requires, and whether your team is comfortable operating a Next.js application alongside a self-managed PostgreSQL or MongoDB database. Payload supports MongoDB, PostgreSQL and SQLite, so the database choice is one of the first decisions to document.
Engagements are fixed-scope. Before work starts, we agree the scope, deliverables and timelines in writing, so you know what is included in areas such as database and object storage setup, the Next.js hosting configuration, the content migration path from the Sanity dataset export, backup and restore procedures, and handover documentation. Ongoing support, upgrades and continuous testing are available as retainers, which matters because Payload's v4.0.0 beta line is in progress and upgrade planning should be part of the written scope. Ask any vendor, including us, to show you which of those items sit inside the fixed price and which become separate work.
DeployOpen does not publish a price list. A quote follows from the written scope, so the most useful preparation is an inventory of your Sanity schemas, datasets, asset volume, editor count, environments and hosting constraints. Share that inventory and the decisions above with us, and we will return a scope that states what is planned, what your team owns and what is out of scope. Confirm current Payload licensing, release status and database support directly with the Payload repository before the scope is signed, and confirm your residency and exit requirements with your legal and security teams.
