DatoCMS vs Payload

DatoCMS and Payload are both headless: they store content and serve it to a frontend your developers build. DatoCMS is a hosted service with a polished editing app, a GraphQL delivery API and plans metered by records, locales, collaborators and API calls. Payload is an open-source TypeScript application that installs into a Next.js project, with the content model, access rules and hooks in your repository and capacity set by your hosting.

This page compares DatoCMS’s current plans and features, checked on 29 September 2026, with Payload 3, through one site that suits both: a multilingual, content-heavy marketing site.

The short decision

Choose DatoCMS when editors work across several locales, the site fits a Professional project’s allowances, and nobody wants to run the CMS. Visual editing, sandbox environments and a GraphQL API come with the subscription.

Choose Payload when the governance you need, such as approval stages or locale-specific permissions, would otherwise mean an Enterprise contract, or when content should live in your own database without per-record and per-call pricing. Payload can be hosted by your team, deployed from Vercel or Cloudflare templates, or hosted by Payload under an enterprise agreement.

One multilingual marketing site, from editing to exit

The comparison below follows an illustrative site: a company publishing product pages, case studies, a resource library and news in six languages, with about a dozen editors and translators and a Next.js frontend.

Daily editorial work

On DatoCMS, editors work in a web app built around models and records. Pages are assembled from a block library that can be reused across models, placed in modular content fields or inside Structured Text. Visual editing lets an editor open the website in draft mode, click an element and land in the right field, or edit side by side through the Web Previews plugin while the preview updates as they type. Localization is strong for this site: a record can carry only some of the six languages, each locale can be published on its own, and fallback locales can be chained. Scheduled publishing can also publish the records a page links to at the same moment.

On Payload, editors work in an admin panel whose fields, blocks and layout come from the TypeScript config. Live Preview shows the draft rendered by your frontend next to the form. Localization is field-level with fallback, and one document holds every language; publishing a document’s locales independently depends on a feature Payload labels experimental and in beta. Scheduled publish and unpublish run as background jobs, so the application needs a jobs runner.

For six languages and a dozen people, DatoCMS gives more out of the box. Payload can come close with Live Preview and custom admin work, and someone has to configure it.

Governance

The site needs translators who edit only their languages and a review step before publishing. On DatoCMS, both are Enterprise features: locale-specific permissions are available on Enterprise, and Workflows, with custom stages and stage-aware permissions, are available only to Enterprise customers. Audit logs and SSO are Enterprise as well.

On Payload, access control is a set of TypeScript functions per collection, document, field and operation, so “translators edit only German fields” or “partners edit only their own entries” is code the team writes and reviews. Named approval stages are Payload’s enterprise Publishing Workflows or custom work. Either way the requirement costs something: an Enterprise contract on DatoCMS, development time on Payload.

Frontend integration

DatoCMS serves content through a GraphQL Content Delivery API, with a REST Content Management API for scripts and migrations and a Real-time Updates API for live previews. Visual editing is frontend work: draft mode, real-time updates and click-to-edit metadata are wired into the site, with guides for Next.js and other frameworks. Images come through an imgix host with on-the-fly transformations. Sandbox environments are forks of the primary environment, so model changes can be tested on real content before promotion.

Payload runs inside the Next.js application. Server components can read content through the Local API without an HTTP call, and REST and GraphQL are generated for other clients. Uploads are collections with image resizing, stored locally or through storage adapters such as S3, R2 and Vercel Blob. Environments are separate deployments with their own databases, so staging is whatever the team provisions. The trade is setup work in exchange for one codebase with no API metering.

Procurement

DatoCMS prices per project. The Free plan allows 2 editors, 300 records, 10 GB of traffic and 100,000 delivery API calls a month, with no overages. Professional starts at €149 a month billed annually, or €199 monthly, and each project includes:

• 10 collaborators, then €9 a month each, up to 100.
• 5 locales, then €19 a month each, up to 10.
• 3 sandbox environments, then €39 a month each, up to 8.
• 100 models and 100,000 records, extendable to 200 models and 200,000 records.
• 1 million delivery API calls, 100,000 management API calls and 1 TB of traffic a month, with pay-as-you-go above them.
• 500 GB of file storage, 50,000 minutes of video streaming and 60 days of history.

Enterprise is by quote and adds workflows, locale permissions, SSO, audit logs and SLAs. For the illustrative site, six languages mean one extra locale on Professional, and the review step means Enterprise.

Payload’s core is MIT-licensed, with no licence, seat or API fee. The budget goes to hosting, the database and storage, building and maintaining the application, and any enterprise agreement for support, SSO or hosting from Payload. Price both over the same period for the same editors, languages, traffic and environments.

Leaving

DatoCMS makes content reachable through its APIs, and its export documentation gives a script that dumps every record through the Content Management API and another that downloads every asset. Marketplace plugins such as Project Exporter do the same without code, and Enterprise customers can have a periodic export sent to their own cloud storage. Models, blocks, Structured Text and the frontend queries written against the GraphQL API are rebuilt on the next platform.

Leaving Payload, the content is already in a database you control and the schema is in your repository. The work is rebuilding the model, admin and access rules elsewhere; our guide to migrating off Payload covers that direction.

When staying on DatoCMS is the better call

Stay on DatoCMS when the editorial experience is what the team values most, the project fits Professional’s allowances, and approval stages are not required. Its localization, visual editing and sandbox environments take configuration work off the developers, and the vendor runs the CMS. Add-ons for an extra locale or more collaborators usually cost less than a replatform.

What a move to Payload rebuilds

A move re-implements what sits around the content. Plan for the models and the block library as Payload collections and blocks; Structured Text converted to Lexical; the frontend’s GraphQL queries rewritten against Payload’s APIs; visual editing replaced by Live Preview or custom work; roles and any workflow as access rules; locales and fallback rules; assets moved off the imgix host with their image transformations recreated; and redirects for any path that changes. WAYF’s CMS replatforming service covers that move.

Two decision scenarios

Both scenarios are illustrative. They are not client projects.

A multilingual marketing team that fits Professional. A travel brand publishes destination guides and offers in five languages, with eight editors and about 40,000 records on a Next.js site. Publishing rights are simple: editors publish their own work. The recommendation is DatoCMS on Professional. The locales, collaborators and records fit the included allowances, per-locale publishing matches how the team works, and visual editing lets editors fix a page from the page itself. Payload would add application work for no capability the team is missing.

Governance and reuse beyond the plan. A software company runs its site in twelve languages, with translators who may edit only their locale, a legal review before publishing, and product data that its app reads from the same content. On DatoCMS that means Enterprise for workflows and locale permissions, and twelve locales exceed Professional’s ten. Payload fits: translator and review rules become access functions, twelve locales are configuration, and the app and site share the collections. The move rebuilds the frontend queries, previews and block library, so price that work against the Enterprise quote.

A short evaluation checklist

Run these with your own project before choosing:

• Allowances. Read the project’s usage page: records, locales, collaborators, API calls, traffic and video minutes, against the plan.
• Governance. List every rule about who can edit or publish what, and mark which ones need Enterprise on DatoCMS.
• Languages. Count the locales now and in two years, and decide whether locales publish independently.
• Editing. Time one page change with visual editing on DatoCMS and Live Preview on Payload.
• Frontend. List the GraphQL queries, preview routes and image transformations the site depends on.
• Environments. Decide how model changes are tested before they reach production.
• Exit test. Run the record and asset export scripts on a copy and list what the next platform would need.

A note on our position

WAYF is an official Payload partner and top contributor, so we have an interest in this comparison. We recommend staying on DatoCMS when a multilingual editorial team is well served by its editing experience and the plan fits.

If you choose Payload, WAYF’s Payload development service covers the build. For a move from DatoCMS, plan the replatforming around the models, locales and previews that need to move.