Pick Strapi if you want the CMS to run as its own Node.js service, with an admin panel where content types can be built by clicking and a REST API that any client calls. Pick Payload if your product is a Next.js app and you want the CMS to live inside that app, configured in TypeScript and deployed with it.
Both are open source, run on Node.js and can be self-hosted with no licence fee. What separates them is the system you end up operating: one extra service, or one larger app.
How do Strapi and Payload differ in architecture?
Strapi is a standalone server. You run npx create-strapi@latest, get a project with its own admin panel, and deploy it as a separate Node process next to a SQL database. Your website, mobile app or internal tool talks to it over HTTP. That helps when several front ends read from one backend, since none depends on another’s codebase.
Payload 3 installs into a Next.js app. The admin panel is a route in that app, the REST and GraphQL endpoints come from the same deploy, and server components can call Payload’s Local API to read straight from the database with no network hop. One repository and one pipeline cover the CMS and the site.
The database choice follows the same split. Strapi 5 supports PostgreSQL 14, MySQL 8, MariaDB 10.3 and SQLite 3, and its documentation says MongoDB is not supported. Payload has official adapters for MongoDB, Postgres and SQLite, with migrations on the relational adapters.
Strapi vs Payload at a glance
| Strapi 5 | Payload 3 | |
|---|---|---|
| Runs as | Separate Node.js server | Part of your Next.js app |
| Databases | PostgreSQL, MySQL, MariaDB, SQLite | MongoDB, Postgres, SQLite |
| Schema authoring | Content-type Builder in the admin, or JSON schema files | TypeScript config only |
| APIs | REST by default, GraphQL as a plugin | Local API, REST, GraphQL |
| Server-side logic | Controllers, services, policies, middlewares | Hooks and access functions in the config |
| Auth for end users | Users and Permissions plugin | Any collection can be an auth collection |
| Paid tiers | Growth and Enterprise licences, Strapi Cloud | Enterprise |
| Core licence | MIT (Community) | MIT |
How does content modelling compare?
Strapi gives you two ways in. A developer, or a product owner sitting with one, can open the Content-type Builder and add collection types, single types, components and dynamic zones in a form. The builder only runs in the development environment, and the result is written to schema files in the project, so changes still go through git and code review. That visual entry point matters to teams where the person who understands the content is not the person who writes TypeScript.
Payload has one way in: code. A collection is a TypeScript object listing its fields, validation, hooks and access rules side by side. Payload generates types from that config, so a renamed field breaks the build in the front end instead of breaking a page in production. Blocks fields cover what Strapi calls dynamic zones, and groups and arrays cover components.
For rich text, Strapi 5 ships a Blocks editor that stores JSON, plus a Markdown field. Payload uses a Lexical based editor configured in code.
What do editors get in each admin?
Strapi’s admin is a separate application with its own login, roles and media library. Editors see a Content Manager organised by type, with draft and publish built in. On the free Community plan there is no Live Preview, no Releases and no Content History; those arrive with the paid Growth licence, and Review Workflows with Enterprise.
Payload’s admin lives on the same domain as your site. Drafts, versions and live preview are part of the open source core, so a small team gets a preview flow without a licence. The admin is React inside your app, which means a custom field or a dashboard widget is an ordinary component your front end developers already know how to write.
How do the APIs and custom logic compare?
Strapi generates a REST endpoint for each content type and needs explicit populate rules to return relations, which keeps responses small but surprises newcomers. GraphQL is a separate plugin. Custom behaviour goes into controllers, services, policies and middlewares, and backend code reads data through the Document Service API.
Payload exposes the same operations three ways. Inside Next.js you call the Local API with full types. Outside, the REST and GraphQL endpoints mirror it. Access control is a function per collection, field and operation, so rules like “a customer sees only their own orders” are a few lines of TypeScript rather than a custom policy.
Extensibility and ecosystem
Strapi has a Marketplace of plugins and providers for uploads, email and search, built up over many major versions. Check Strapi 5 support before you rely on one. Payload’s plugin system is a function that receives the config and returns a changed one, which makes writing your own plugin easy and leaves the official set, such as SEO, forms, redirects and nested docs, smaller in number.
What does each cost to own?
The licence cost of both can be zero. As of October 2026, from Strapi’s pricing pages:
| Strapi option | Price as of October 2026 | What it adds |
|---|---|---|
| Community, self-hosted | Free | MIT licence, unlimited users, RBAC |
| Growth, self-hosted | $45 a month for 3 users, $15 per extra user | Releases, Content History, Live Preview |
| Enterprise | Contact sales | Review Workflows, SSO, Audit Logs |
| Strapi Cloud | From $35 per project a month | Managed hosting, CDN, backups from Pro ($90) |
Payload sells an Enterprise tier for features such as SSO and publishing workflows, and its core is MIT. Payload announced in June 2025 that it was joining Figma and said the project stays open source with self-hosting unchanged.
For both, people cost more than licences: someone hosts the database, patches Node and runs major upgrades. With Strapi that is a second service to watch. With Payload a CMS upgrade becomes part of your app’s release.
Migrating between Strapi and Payload
From Strapi to Payload, run strapi export with encryption off to get content, relations, schemas and assets in an archive. Admin users and API tokens are not exported, so recreate them. Map each content type to a collection, components to groups, dynamic zones to blocks fields, and Blocks rich text to Lexical nodes. Then rewrite front end queries, which is usually the longest step.
From Payload to Strapi, the content sits in your own database, so you script the export directly. Recreate collections as Strapi content types and move access functions into roles and policies. Logic held in Payload hooks needs a new home in Strapi lifecycles or Document Service middlewares. Our CMS migration checklist lists the URL and redirect checks we run either way.
Proof from a Payload build
For a European mid-market B2B SaaS company leaving WordPress, we built the content layer in Payload with Next.js: typed collections, a localisation plugin for five markets and CI from staging to production. The B2B SaaS Payload build reports a ~65% reduction in time-to-publish and an LCP of 1.7s, down from 4.2s. We chose Payload because the team already worked in TypeScript and Next.js. We have not published a Strapi case study yet.
Which one we would pick for whom
- A Next.js product team that wants one deploy: Payload.
- An organisation with several front ends, including mobile, sharing one backend: Strapi, kept as its own service.
- A team on MongoDB: Payload, because Strapi 5 does not support it.
- Marketing teams that want a product owner to shape content types without code: Strapi, for the Content-type Builder.
- Apps where the CMS also stores customers, orders or permissions per record: Payload, for its auth collections and access functions.
- Teams that want a vendor to host it: Strapi Cloud, since Payload’s managed hosting is tied to Enterprise.
For the full picture of each platform, see our Strapi development services and Payload CMS development pages. To add people to an existing team, hire a Strapi developer or hire a Payload developer. If access rules decide it, our guide to headless CMS platforms with roles and permissions compares both, and the free headless CMS comparison covers free tiers. Our headless CMS development page explains how we scope a build.
For the hosted alternative to both, read Payload vs Sanity.
