Skip to main content

Payload CMS v3 vs Strapi v5 for SaaS Boilerplates 2026

·StarterPick Team
cmspayload-cmsstrapisaas-boilerplate

Choosing a CMS for a SaaS product is not just a content question — it shapes your database schema, your admin UI, your API layer, and your deployment costs. In 2026, Payload CMS v3 and Strapi v5 are the two dominant open-source headless CMS options for teams building on modern JavaScript stacks. They take fundamentally different approaches to the same problem, and the right choice depends on your team structure, your existing stack, and how much control you want over the content schema.

What Changed in Each Version

Payload CMS v3

Payload 3.0, released in late 2024, made a single architectural bet: go Next.js native. The CMS installs directly into an existing Next.js app folder, combines the admin panel and front end into one unified project, and deploys serverlessly to Vercel out of the box.

Key v3 changes:

  • The admin panel is built on Next.js App Router and can be customized with your own React components
  • The Local API queries the database directly — no HTTP layer overhead
  • Dependencies dropped from 88 (v2) to 27 (v3)
  • Turbopack support built in from the start
  • Payload can now be installed into an existing Next.js project with npx create-payload-app@latest

As of early 2026, Payload has reached v3.1.0 with improved local API performance and enhanced TypeScript support throughout the schema definition system.

Strapi v5

Strapi v5, released in 2024, was a major rewrite with significant breaking changes from v4. The new Document Service API replaced the Entity Service API, content versioning is now available on all plans (not just paid tiers), and the admin panel received a UI overhaul.

Key v5 changes:

  • Document Service API replaces Entity Service API (breaking change for v4 projects)
  • Draft and publish, with content versioning, available on the free tier
  • New plugin system with better isolation
  • Improved TypeScript coverage in the core (though still less complete than Payload)
  • Strapi Cloud as the managed hosting option

As of 2026, Strapi has reached v5.1.0 with performance, security, and scalability improvements.

Architectural Philosophy

The core difference between these two CMSes comes down to one question: who controls the schema?

Payload: Schema is code. You define your collections, fields, access controls, and hooks in TypeScript configuration files. There is no GUI for schema editing — your data model lives in your repository, is version-controlled, and is the same in every environment. This is the approach backend developers tend to love and content editors tend to find opaque.

Strapi: Schema can be managed from the admin UI. Non-technical team members can add content types, modify fields, and configure access without touching code. This is the approach content teams love and developers tend to approach with caution (schema changes from a GUI need careful environment promotion).

Neither approach is wrong. They reflect different assumptions about who is doing the configuration.

Database Support

Payload v3 is database-agnostic. You choose:

  • PostgreSQL for relational projects (most production SaaS)
  • MongoDB for document-oriented data
  • SQLite for rapid local development and prototyping

This flexibility is practical. Start with SQLite locally, promote to PostgreSQL in production, and never rewrite your queries.

Strapi v5 is SQL-only. MongoDB support was officially dropped. The supported databases are PostgreSQL, MySQL, SQLite, and MariaDB. This is less flexible than Payload but covers the most common production cases.

TypeScript Developer Experience

Payload is TypeScript-native by design. You define your data model in TypeScript, and the types propagate automatically through the Local API, the REST API, and your custom hooks. A field added to a collection is immediately typed throughout your application — no code generation step required.

// payload.config.ts
import { buildConfig } from "payload/config"

export default buildConfig({
  collections: [
    {
      slug: "posts",
      fields: [
        {
          name: "title",
          type: "text",
          required: true,
        },
        {
          name: "publishedAt",
          type: "date",
        },
        {
          name: "author",
          type: "relationship",
          relationTo: "users",
        },
      ],
    },
  ],
})

Strapi v5 has improved TypeScript support but the experience is less seamless. Schema defined through the admin UI generates TypeScript types, but the cycle is: edit schema in UI → generate types → update code. For teams who use Strapi's schema editor heavily, this is a manageable workflow. For teams who define everything in code, it is an extra step.

Next.js Integration

This is Payload's strongest selling point. Because Payload v3 runs inside your Next.js app, you access it with the Local API in Server Components:

// app/blog/[slug]/page.tsx
import { getPayload } from "payload"
import config from "@payload-config"

const payload = await getPayload({ config })

const post = await payload.findOne({
  collection: "posts",
  where: {
    slug: { equals: params.slug },
  },
})

No HTTP request. No API key. Direct database access with full TypeScript types. This is a fundamentally different developer experience than using a headless CMS via REST or GraphQL.

Strapi integrates with Next.js via its REST or GraphQL API in the traditional headless CMS pattern. You make an HTTP request from your Next.js app to the Strapi server:

// app/blog/[slug]/page.tsx
const response = await fetch(
  `${process.env.STRAPI_URL}/api/articles?filters[slug][$eq]=${params.slug}&populate=*`,
  {
    headers: {
      Authorization: `Bearer ${process.env.STRAPI_API_TOKEN}`,
    },
  }
)
const { data } = await response.json()

The Strapi approach is well-understood and works fine, but it requires the Strapi server to be running separately from your Next.js app.

Content Versioning

Both CMSes now support content versioning on the free tier as of their v3/v5 releases.

Payload highlights the diff between any two versions of a content entry. You can compare exactly what changed between a draft and the published version. Visual editing support lets editors click, point, and edit content in context without navigating to the CMS admin.

Strapi supports draft and publish with versioning, but the comparison UI does not highlight the diff between versions — you see the full content of each version side by side. Visual editing redirects to the CMS admin UI for changes rather than allowing in-context editing.

Localization

Payload handles localization at the field level. Add localized: true to any field definition and Payload manages the locale variants as part of the document:

{
  name: "title",
  type: "text",
  localized: true,
}

Strapi uses the @strapi/plugin-i18n plugin, which stores each localized record as a separate database row with a locale field. This is a more traditional CMS approach and works well, but the schema is more complex and querying localized content requires explicit locale parameters.

Hosting and Cost

Payload v3 deploys to Vercel as a serverless Next.js app. If you are already deploying to Vercel, there is no additional server to manage. Costs are Next.js compute + database hosting (Neon, Supabase, or any PostgreSQL provider).

Strapi v5 runs as a Node.js server. You need a persistent server process, which means a VPS or container-based hosting (Railway, Render, Fly.io) rather than serverless. The Strapi Cloud managed option simplifies this at a cost.

Hosting scenarioPayload v3Strapi v5
VercelNativeNot supported
ServerlessYesNo
VPS/ContainerYesYes (natural fit)
Managed hostingVercelStrapi Cloud
Estimated cost$0-20/mo (Vercel + DB)$29-99/mo (server + DB)

Admin UI and Non-Technical Users

Strapi's admin UI is polished and approachable for content editors and marketing teams. Non-developers can add content types, manage media, and configure access without touching code. This is Strapi's strongest advantage for teams with a content editor role.

Payload's admin UI is React-based and fully customizable, but the out-of-the-box experience is more technical. Content editors can use the Payload admin to manage entries, but they cannot modify the schema — that is code-only. For teams where developers control the schema and editors only manage content, this is fine. For teams where content editors need schema control, Strapi is a better fit.

Plugin Ecosystem

Payload has a growing plugin ecosystem with packages for SEO, form handling, Stripe integration, and media cloud storage. The ecosystem is smaller than Strapi's but is growing quickly since the v3 Next.js-native release attracted a larger developer audience.

Strapi has a mature plugin marketplace with hundreds of plugins accumulated over its longer history. More integrations are available out of the box without custom code.

SaaS Boilerplate Compatibility

Several SaaS boilerplates have shipped Payload v3 integrations. Our Payload CMS starter review covers the most notable options in detail. For teams comparing across CMS options, the Payload vs Sanity vs Strapi starter comparison covers the broader landscape.

When to Choose Payload v3

  • Your front end is Next.js (the Local API integration is uniquely powerful)
  • Your team is developer-heavy with TypeScript experience
  • You want serverless deployment without managing a separate CMS server
  • Schema changes go through code review and version control
  • You need tight type safety between your CMS schema and your application code

When to Choose Strapi v5

  • You have a content team that manages schema through a GUI
  • You are not on Next.js (Strapi's REST/GraphQL API is framework-agnostic)
  • You need the mature plugin ecosystem for third-party integrations
  • Your hosting setup favors persistent server processes over serverless
  • You are migrating from a traditional CMS and want a familiar admin interface

Migration Notes

Strapi v4 to v5 is a breaking migration. The Document Service API is a complete replacement for the Entity Service API, and all custom plugins need updates. Strapi provides migration guides, but the effort is non-trivial for projects with custom plugins or complex access policies.

Payload v2 to v3 is also a significant change. The Next.js App Router requirement, the new config structure, and the serverless deployment model all require updates. Payload provides a migration guide and the @payloadcms/migrate tooling.

If you are starting a new project in 2026, start with v3/v5 of whichever CMS you choose. Do not build on Payload v2 or Strapi v4 — both are in maintenance mode.

Final Recommendation

For Next.js SaaS projects in 2026, Payload v3 is the stronger technical choice. The Local API performance, the TypeScript-native schema, the serverless deployment, and the zero-overhead Next.js integration are meaningfully better than what any other CMS offers for the Next.js stack.

Strapi v5 remains the better choice when your team has non-technical content editors who need schema control, when your front end is not Next.js, or when the Strapi plugin ecosystem has specific integrations you depend on.

The boilerplate ecosystem has caught up to both. You can find production-ready SaaS starters for either CMS without building the integration yourself. The choice comes down to team structure and stack, not boilerplate availability.

Comments