Strapi vs Payload

Strapi and Payload are both open-source, self-hostable, JavaScript-native headless CMSes with zero licensing cost on their core editions, but they are not interchangeable. Strapi takes a GUI-first, SQL-based approach with a large, established plugin ecosystem. Payload takes a code-first, TypeScript approach that runs inside Next.js. The decision between them is an architectural one.

The core difference

Strapi’s philosophy is configuration as a product. Its Content-Type Builder is a GUI in the admin panel where developers and content strategists define content types by clicking through a form, and the platform generates the corresponding schema files behind the scenes. That makes it approachable for teams that want to prototype schema changes without writing code, and it produces an admin panel non-technical users can pick up quickly.

Payload’s philosophy is code-first. There is no GUI schema builder. Collections, fields, blocks, access control, and hooks are defined in configuration files, and all of them are imported into payload.config.ts as the single entry point. Because the schema lives in code, every content-model change goes through a pull request and ships through the same review, testing, and CI/CD pipeline as the rest of the application.

This difference propagates through the entire development and operational experience. It is the first thing to evaluate before any other comparison.

Database support and schema definition

Strapi v5 is SQL only. It officially supports PostgreSQL, MySQL, MariaDB, and SQLite; MongoDB support was removed in v4. Payload supports PostgreSQL, MongoDB, and SQLite. Strapi is the fit when the database is fixed to MySQL or MariaDB. Payload keeps the database choice open, including MongoDB.

Strapi content types can be defined through the Content-Type Builder UI during development, through JSON schema files, or through both. The builder writes a schema.json file for each content type. The Content-Type Builder is development-only, so staging and production receive schema changes through a code deployment; Strapi’s deployment guide asks teams to review those changes before release. The models documentation covers the generated model files.

Payload content types are defined in TypeScript. payload.config.ts and the files it imports are the single source of truth for collections, fields, globals, and access control. Both approaches can pass pull-request review; the reviewer reads generated JSON in Strapi and authored TypeScript in Payload.

Next.js integration

Payload 3.0 runs inside a Next.js application. The admin panel, rendering layer, and API share one deployment, and the Local API lets Server Components query data as typed function calls. Payload generates payload-types.ts from the config, automatically in development or with payload generate:types in CI.

// 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: { _status: { equals: 'published' } },
  })
  return <PostList posts={posts.docs} />
}

Strapi is a separate backend service consumed through REST or GraphQL:

// Strapi REST API from a Next.js Server Component
export default async function BlogPage() {
  const res = await fetch(
    `${process.env.STRAPI_URL}/api/posts?status=published`,
    { headers: { Authorization: `Bearer ${process.env.STRAPI_TOKEN}` } },
  )
  const { data } = await res.json()
  return <PostList posts={data} />
}

Strapi’s ts:generate-types command generates backend types, but the frontend remains across a network boundary; Strapi’s TypeScript documentation describes the current integration path. Payload can also expose REST and GraphQL or run outside Next.js through its Local API.

Admin, plugins, and AI agents

Payload’s admin panel is generated from configuration and can be extended with custom React fields, views, and panels. Strapi provides a polished panel out of the box. Full-screen Preview is free; Live Preview, Releases, and Content History are on Growth, while Review Workflows are on Enterprise.

Strapi’s marketplace is broader and more established, with variable community-plugin support and v5 compatibility. The v4-to-v5 migration guide lists plugin migration among the breaking changes. Payload’s official plugins are a smaller, more consistent set.

Strapi’s built-in MCP server is opt-in from 5.47.0 and answers at /mcp on the project’s own instance. A collection type generates up to eight tools, and content-management tools are gated by an Admin token’s permissions. Payload’s first-party MCP plugin serves /api/mcp from the deployment and authorises requests with an API key by default. Scope either token before allowing writes. Strapi MCP audit logs record content changes, excluding reads, on Enterprise from 5.52.0.

Where Strapi is the stronger choice

Strapi wins when the database has to be MySQL or MariaDB. Payload also covers PostgreSQL and SQLite, so “we use SQL” on its own is not a reason to prefer Strapi. The genuine gap is MySQL and MariaDB: Strapi supports both, Payload does not.

It also fits teams that need a visual interface for schema iteration. Agencies onboarding new clients, teams where a content strategist needs to propose schema changes, and projects where the content model is still being discovered benefit from Strapi’s Content-Type Builder.

Strapi’s broader marketplace is useful when a project requires specific third-party integrations, but critical plugins need a v5 compatibility check before the team commits.

If the project requires integrations such as Algolia, Cloudinary, Sentry, or marketing automation, verify each critical plugin’s v5 support before committing. Strapi is also a comfortable decoupled choice when Next.js is off the table and the team wants a GUI-driven backend; Payload still serves non-Next.js frontends over REST and GraphQL, so the decision returns to the code-first-versus-GUI tradeoff.

Where Payload is the stronger choice

Payload wins when the team is TypeScript and Next.js native. The Local API, same-project deployment, and automatic type generation produce a development experience that TypeScript engineers find faster than working across a network boundary.

It is also the better fit when schema review should read like code. Organisations where infrastructure changes require code review, pull-request approval, and CI/CD deployment treat Payload’s code-first schema as a requirement rather than a preference. Strapi’s builder also writes its schema into the project, so both can be reviewed; in Strapi the reviewer reads generated JSON rather than authored TypeScript.

Payload’s access control is more precise for complex content platforms: function-based logic can handle per-field, per-user, and per-document rules in TypeScript.

A worked example: a Next.js marketing site with several editors

This example is illustrative. It is not a client project, and it uses published documentation and prices checked on 29 September 2026 rather than a test or benchmark.

A B2B company runs its marketing site on the Next.js App Router, in one language. Six people write pages and posts. A brand lead approves landing pages before they go live. Editors want to preview an unpublished page in the real frontend, and a product launch sometimes needs several pages to go live together.

The approval path matters. Strapi’s role-based access control can give editors draft rights and a brand lead publish rights per content type. Payload’s drafts documentation shows an update rule that hides Publish for editors and can prevent editors from updating published documents; the team should test the complete edit and approval path rather than assume the example covers every page state. Staged review is Strapi’s Enterprise Review Workflows or Payload’s enterprise Publishing Workflows, otherwise custom work on drafts and access control.

For preview, Strapi’s full-screen Preview is free and side-by-side Live Preview needs Growth. Payload’s Preview and Live Preview are in core. On either platform, the Next.js frontend implements draft mode to fetch unpublished content. Strapi Releases publish several entries together on Growth; Payload schedules documents individually in core and needs a running jobs queue, so grouped launches need coordination or custom work.

Seven people need admin access in this illustration. Strapi Growth costs $45 a month for three seats plus $15 for each further seat, or $105 for seven, and includes Live Preview, Releases, and 14 days of Content History. Payload charges nothing per editor on its open-source core; budget hosting and operations separately.

If one-step approval is enough, either free edition can work. Payload keeps preview, scheduling, and the content model in the same TypeScript codebase. Strapi reaches the same editorial feature set on Growth and adds Releases. If the brand lead needs staged review, ask both vendors for enterprise quotes before deciding; neither enterprise price is published. Staying on Strapi is reasonable when its current plan covers preview and approval, or the database must be MySQL or MariaDB; moving means rewriting the model, migrating data, and changing frontend fetching. The Strapi migration guide covers that route. Payload also offers enterprise hosting, so a quote should specify who operates the deployment; a self-hosted Strapi setup runs beside the Next.js frontend.

Pricing and total cost of ownership

Strapi’s Community Edition is MIT-licensed and free to self-host. Governance features live on Strapi’s paid CMS plans: Growth starts around $45 per month for three seats plus $15 per additional seat, and Enterprise requires a sales quote. Growth adds Strapi AI, live preview, releases, content history, and basic support; audit logs and multi-stage review workflows are Enterprise features. SSO is a Growth add-on at $150 per month, covering the same three seats the plan does, so three editors with SSO cost $195 per month and each seat above the third adds $65; Enterprise includes it.

Payload’s open-source core includes granular, function-based access control, document version history, and unlimited editor accounts with no per-seat charge. On the free core, SSO comes from community plugins covering OAuth 2.0, without a SAML option, or from a custom auth strategy, and review gates are built on core drafts and versions. Payload licenses SSO, publishing workflows, and a system-wide audit log as enterprise features, sold through a sales-led enterprise engagement with dedicated engineering support and no published price list.

The difference is in how each one prices governance: Strapi publishes its Growth and add-on rates and meters editor seats from the Growth plan up, while Payload quotes its enterprise licence per engagement. Neither meters editors on its free edition.

For document history, Strapi Growth retains 14 days and Enterprise retains 30 days by default, up to 90. Payload versions are built in and opt-in per collection, with 100 versions per document once enabled. These retention details are kept here because the shared comparison matrix is the current feature source.

Payload’s core versions keep document snapshots, diffs and restore, but no user field by default; that is not a system-wide audit log. Strapi’s role model includes per-field and per-locale permissions and custom conditions, while Payload access functions can combine user and document data in one rule.

For historical context, the 28 September 2026 snapshot recorded roughly 73,000 GitHub stars for Strapi and 45,000 for Payload. Those are dated popularity counts, not evidence that either fits a particular project better.

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.

A note on our position

WAYF is an official Payload partner and top contributor, so we have an interest in this comparison. We build content platforms and CMS migrations on Payload and Next.js. When a team’s stack, plugin needs, or existing Strapi investment make Strapi the better fit, that is the recommendation we give — both are open source systems a team can genuinely own.

The closest published example is Ingersoll Rand: a custom Next.js frontend on Payload, with more than 20 brand tenants in China, role-based access tied to tenants, and a publication workflow for page collections. If you are weighing Payload against Strapi for a specific project, our content platform team can take the worked example through your requirements.

If you choose Payload, see WAYF’s Payload development service for new builds and ongoing engineering. For an existing Strapi application, CMS replatforming scopes the content model, integrations and cutover before implementation.

Further reading and sources

• Strapi, v5 documentation
• Strapi, CMS pricing and plans
• Strapi, v4 to v5 upgrade guide
• Payload CMS, what is Payload
• Payload CMS, database overview
• Payload CMS, Local API reference
• Payload CMS, enterprise features
• Payload CMS, enterprise audit logs
• Strapi, MCP server
• Payload CMS, MCP plugin
• Strapi, Content-Type Builder
• Strapi, role-based access control, Preview, Releases, Review Workflows, and Content History
• Payload CMS, generating TypeScript types
• Payload CMS, versions and drafts
• Payload CMS, Live Preview
• Payload CMS, Publishing Workflows
• Payload CMS, deployment options

Sources rechecked 29 September 2026. Prices are Strapi’s published rates on that date; Payload publishes no enterprise price.

Decided on Payload? Read the Strapi-to-Payload migration guide →