Payload 3.0 typically ships and deploys faster than Strapi v5 when your frontend is Next.js. Its local API and embedded architecture remove a separate server and network hop from every content request. Strapi v5 stays the better fit for multi-frontend projects or teams that need a GUI-first schema builder rather than raw speed.

Key takeaways

  • Payload 3.0 runs inside Next.js and reads content through a local API. This skips the network hop that Strapi's separate Koa server always requires.
  • Strapi v5's decoupled REST/GraphQL API suits projects serving multiple frontends (web, mobile, kiosk) from one CMS.
  • Payload's free, self-hosted tier includes field-level access control, versioning, and live preview. Strapi gates review workflows, audit logs, and SSO behind paid tiers (Strapi pricing, Payload pricing).
  • On our SleepDr.com migration to Next.js 15 and Payload CMS, Lighthouse performance rose from 35 to 94 (case study).
  • Pick Payload for TypeScript-heavy Next.js builds. Pick Strapi for GUI-first content modeling or multi-platform delivery.

Updated 15 August 2026: sources added, experience claims checked against our project record, summary added.

Payload and Strapi take genuinely different architectural approaches, and picking the wrong one tends to mean rebuilding the CMS layer later, usually at the worst possible time. The sections below cover architecture, developer experience, performance, pricing, and hosting so you can match the tool to your stack before you're locked in.

Architecture and Core Philosophy

Payload CMS 3.x

Payload 3.0 wasn't a small update. It was a full rewrite. The CMS now runs inside a Next.js application, not alongside it, not behind it. Your admin panel, API routes, and frontend can all live in the same Next.js project. Payload uses your existing Next.js server, so there's no separate Express process to babysit, no separate port to open, and no reverse proxy headaches to debug at 2am.

The database layer supports both MongoDB and PostgreSQL via Drizzle ORM, with SQLite available for local dev. Payload builds its own database schema from your config and handles migrations for you. It also gives you a fully typed local API that skips HTTP entirely when called from server components or API routes.

// Calling Payload's local API from 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' } },
    limit: 10,
  })
  return <PostList posts={posts.docs} />
}

This is a real shift: you're not making HTTP requests to a CMS. You're calling a function in the same process. That difference matters more than it sounds like it should on paper.

Strapi 5.x

Strapi 5 shipped with a new document-based content architecture that replaced the older entity service API. It runs as a standalone Node.js server (Koa under the hood) and exposes REST and GraphQL APIs. Your frontend is always a separate app talking over HTTP.

That separation has real upsides, though. You can scale your CMS and frontend independently, and you can serve content to a React app, a mobile app, and a digital kiosk without coupling anything together. It's a more traditional architecture, and traditional doesn't mean wrong.

Strapi 5 supports PostgreSQL, MySQL, MariaDB, and SQLite. MongoDB support was removed in Strapi 4 and has not returned in v5.

Dimension Payload CMS 3.x Strapi 5.x
Runtime Next.js (embedded) Koa (standalone Node.js)
Language TypeScript-first JavaScript-first, TS supported
Database PostgreSQL, MongoDB, SQLite PostgreSQL, MySQL, MariaDB, SQLite
API Style Local API + REST + GraphQL REST + GraphQL
Frontend Coupling Can share Next.js app Always decoupled
ORM Drizzle (SQL) / Mongoose (Mongo) Knex.js (via Bookshelf successor)

Developer Experience

Getting Started

Both CMSs have create commands:

## Payload
npx create-payload-app@latest

## Strapi
npx create-strapi@latest

Payload's scaffolding drops you into a working Next.js app with the admin panel at /admin. You can start editing content within minutes of running the command. The config is a single TypeScript file, payload.config.ts, that defines collections, globals, plugins, and access control. That's it. One file.

Strapi's scaffolding creates a separate backend project. You define content types either through the admin panel's Content-Type Builder (a GUI) or by editing JSON/JS model files directly. Strapi has long been friendlier to non-developers because of that visual builder, which shortens onboarding for a fresh team.

Code-First vs GUI-First

This is the main DX divide, and it's easy to overlook until you're three months into a project and realize your team picked the wrong workflow.

  • Payload is code-first. Every collection, field, hook, and access control rule lives in TypeScript config files. There's no GUI for schema definition in production. You version control everything.
  • Strapi is GUI-optional. You can define schemas in the admin panel during development, and Strapi builds the matching model files. In production, the Content-Type Builder is usually turned off.

For teams with strong engineering habits, Payload's approach wins. Your content schema is always in git, always reviewable, always deployable through CI/CD. But for teams onboarding junior developers or non-technical content strategists who need to change structure quickly, Strapi's visual builder cuts ramp-up time. Know your team before you commit.

Hot Reload and Local Development

Payload 3.x inherits Next.js's hot module replacement. Change your Payload config and the admin panel and API update without a restart. Complex configs with many collections can add noticeable delay to HMR, but it's rarely a dealbreaker.

Strapi 5 supports hot reload in dev mode too, but changes to content-type schemas need a server restart. Field changes through the Content-Type Builder trigger automatic restarts, a different rhythm than hot-reload-everything workflows.

Content Modeling

Field Types

Both platforms offer rich field type systems. Payload's is more detailed:

Field Type Payload Strapi
Rich Text (Lexical/Slate) ✅ Lexical (default), Slate (legacy) ✅ CKEditor 5 / Blocks
Blocks (layout builder) ✅ Native ✅ Dynamic Zones
Arrays ✅ Native ✅ Repeatable Components
Polymorphic Relations ✅ Native ✅ via Dynamic Zones
Tabs/Groups (UI organization) ✅ Tabs, Rows, Collapsibles ⚠️ Limited (components)
Upload/Media ✅ Built-in with image resize ✅ Built-in media library
Versions/Drafts ✅ Built-in ✅ Built-in (v5 improved)
Localization ✅ Field-level ✅ Content-level
Live Preview ✅ Native ⚠️ Requires plugin
Join Fields (virtual) ✅ Native ❌ Not available

Payload's Blocks field is strong for page-builder patterns. You define reusable block types with their own field schemas, and editors build pages by stacking and reordering blocks. It's a similar idea to Strapi's Dynamic Zones, but Payload's version gives you discriminated union types in TypeScript. That's a big deal when you're rendering 15 different block types in a frontend component. Your IDE knows what's what instead of you squinting at a Record<string, any> trying to remember the shape.

// Payload block definition
const heroBlock: Block = {
  slug: 'hero',
  fields: [
    { name: 'heading', type: 'text', required: true },
    { name: 'backgroundImage', type: 'upload', relationTo: 'media' },
    { name: 'ctaLink', type: 'text' },
  ],
}

Localization

Payload supports field-level localization. You mark individual fields as localized while keeping others shared across locales. A product can have a localized description but a shared sku. Clean. Efficient.

Strapi's localization is content-level. You create separate entries per locale and link them. Simpler in concept, but it creates data duplication and makes syncing non-localized fields tedious. Teams managing many-locale Strapi projects often report this duplication as a real pain point.

For multilingual projects, Payload's approach is more efficient and much less error-prone. That makes it the safer pick for i18n-heavy builds.

Performance and Benchmarks

Independently published benchmarks comparing Payload 3.x and Strapi 5 head-to-head are hard to find. So the comparison below focuses on the architectural reasons one is generally faster, rather than on unverified numbers.

API Response Times

Payload's local API skips HTTP entirely when your frontend and CMS share a Next.js process. There's no network round-trip, no request serialization, and no JSON parsing on the way back. That matters most in Next.js Server Components, where a single page can fire several data calls during render. Both Payload's REST/GraphQL APIs and Strapi's REST/GraphQL APIs cross an HTTP boundary the same way, though, so the gap narrows once you compare like for like: decoupled REST call versus decoupled REST call.

Build Times and Cold Start

Payload 3.x inherits Next.js's cold-start behavior on serverless platforms like Vercel; see Vercel's functions documentation for how cold starts scale with function size. Strapi is a persistent Node.js server by design (see the hosting section below), so it isn't built for serverless deployment. Its cold-start profile depends entirely on the host you choose. For traditional server or container deployments, both start up fast enough that cold start isn't a meaningful factor.

Admin Panel and Editorial UX

Payload Admin

Payload's admin panel is a React app rendered within your Next.js app. It uses server components where possible and client components for interactive parts. The panel is functional and opinionated. It favors developer configurability over visual polish, though the gap has closed a lot in v3.

Key editorial features:

  • Live Preview: Editors see real-time changes reflected in an iframe showing the actual frontend. Built-in, not a plugin.
  • Versions and Drafts: Full version history with diff comparison and one-click rollback.
  • Custom Views: Add fully custom React pages to the admin panel: dashboards, analytics, workflow tools, whatever you need.
  • Lexical Rich Text Editor: Built on Meta's Lexical framework. Highly customizable. Add custom nodes, toolbar buttons, even embed React components directly.

Strapi Admin

Strapi's admin panel is polished and easy to use. Non-technical editors generally find it more approachable. The design system is clean, navigation is straightforward, and the Content-Type Builder GUI is a real advantage for teams that want to change schemas visually.

Strapi 5's editorial features:

  • Draft & Publish: Improved in v5 with the document-based approach.
  • Review Workflows: Available on the Enterprise plan. Multi-stage content approval workflows.
  • Content History: Enterprise only.
  • Internationalization: Built-in locale management in the admin.

The editorial UX gap has narrowed a lot. Payload used to feel like a developer tool that editors had to tolerate. Now it's a capable editing environment with real extensibility underneath. Strapi still tends to win on first impressions with non-technical users: in practice, stakeholders often ask fewer onboarding questions after a Strapi demo than after a Payload one.

Authentication and Access Control

Payload

Payload has a built-in authentication system. Any collection can be auth-enabled by adding auth: true to its config. That gives you user registration, login, JWT tokens, refresh tokens, API key authentication, password reset flows, and email verification, all out of the box. No third-party auth service needed.

Access control is function-based and detailed:

const Posts: CollectionConfig = {
  slug: 'posts',
  access: {
    read: ({ req }) => {
      if (req.user?.role === 'admin') return true
      return { status: { equals: 'published' } }
    },
    create: ({ req }) => req.user?.role === 'editor',
    update: ({ req, id }) => {
      if (req.user?.role === 'admin') return true
      return { author: { equals: req.user?.id } }
    },
    delete: ({ req }) => req.user?.role === 'admin',
  },
  fields: [/* ... */],
}

Notice that read access can return a query constraint instead of a boolean. Payload filters data at the database level rather than in application memory. That's a key security and performance feature, easy to overlook until you've tried to build row-level security in a system that doesn't support it natively.

Strapi

Strapi uses role-based access control (RBAC) set up through the admin panel. You define roles (Author, Editor, Admin, etc.) and assign permissions per content type and action. It's configured via the GUI, which is more accessible but less flexible than Payload's programmatic approach.

The Enterprise plan adds field-level permissions and custom conditions. The free tier is limited to role-based access without custom conditions.

For apps that need complex access patterns, like multi-tenant SaaS, user-generated content, or document-level permissions, Payload's function-based access control is far more powerful. It's not even close.

Plugin Ecosystem and Extensibility

Payload

Payload's plugin system is config-based. A plugin is just a function that takes your Payload config and returns a modified config. Simple. Predictable. Easy to reason about.

import { buildConfig } from 'payload'
import { seoPlugin } from '@payloadcms/plugin-seo'
import { formBuilderPlugin } from '@payloadcms/plugin-form-builder'
import { searchPlugin } from '@payloadcms/plugin-search'

export default buildConfig({
  plugins: [
    seoPlugin({ collections: ['posts', 'pages'] }),
    formBuilderPlugin({}),
    searchPlugin({ collections: ['posts'] }),
  ],
})

Official plugins include SEO, redirects, form builder, nested docs, search, Stripe integration, and cloud storage (S3, GCS, Azure, Vercel Blob). The community plugin ecosystem is growing but still smaller than Strapi's. Worth knowing going in.

Strapi

Strapi has a bigger marketplace of community plugins covering Meilisearch, SendGrid, Cloudinary, SEO, sitemap generation, and more; see the Strapi Marketplace. If you need a pre-built integration, someone's probably already built it for Strapi. That's a real advantage when you're on a tight timeline.

Strapi plugins can modify content types, add admin panel sections, and register new API routes. The plugin API is more complex than Payload's but far more established.

Ecosystem Payload Strapi
Official Plugins Small, focused set (SEO, forms, search, Stripe, cloud storage) Broader official plugin set
Community Plugins Smaller, growing library Large marketplace covering most common integrations
Marketplace No formal marketplace strapi.io/marketplace
Plugin API Complexity Low (config transforms) Medium (lifecycle hooks, server/admin)

Pricing and Hosting

Payload Pricing (2026)

  • Free / Open Source: Full feature set, self-hosted. No feature gating.
  • Payload Cloud (Pro): Managed hosting on AWS with built-in S3 storage, email, and database; see Payload pricing for current rates.
  • Payload Cloud (Enterprise): Custom pricing. SLA, SSO, priority support.

The key point: Payload doesn't gate features behind paid tiers. Every feature, including access control, localization, versions, and live preview, is available in the free self-hosted version. Payload Cloud is a hosting convenience, not a feature unlock.

Strapi Pricing (2026)

  • Community (Free): Self-hosted, core features. No review workflows, no content history, no SSO, no audit logs.
  • Strapi Cloud (Team): Managed hosting with collaboration features; see Strapi pricing for current rates.
  • Strapi Cloud (Pro): Adds review workflows and audit logs; see Strapi pricing.
  • Enterprise: Custom pricing. SSO, custom roles with conditions, premium support.

Strapi gates several features behind paid tiers: review workflows, content history, audit logs, SSO, and advanced RBAC conditions. If your team needs these features self-hosted, you're looking at an Enterprise license.

Feature Payload (Free) Strapi (Free) Strapi (Enterprise)
Access Control (field-level) ✅ ❌ ✅
Review Workflows ✅ (custom hooks) ❌ ✅
Content Versioning ✅ ⚠️ Basic ✅ Full
SSO ✅ (via auth config) ❌ ✅
Audit Logs ✅ (via hooks) ❌ ✅
Localization ✅ ✅ ✅

This pricing gap is large. A mid-size project needing content workflows and audit logs costs nothing extra with self-hosted Payload, versus a paid Strapi Cloud tier or an Enterprise contract for self-hosted Strapi. That's a hard conversation to have with a client when the free option exists.

Self-Hosting and Infrastructure

Payload on Vercel

Because Payload 3.x is a Next.js app, you can deploy it to Vercel. The admin panel and API run as serverless functions. You'll need an outside database (Vercel Postgres, Neon, Supabase, or a managed MongoDB instance) and outside file storage (Vercel Blob, S3).

This works well for small to medium projects, but there are caveats: serverless cold starts affect admin panel responsiveness, and large file uploads can hit function timeout limits.

Payload on Traditional Servers

Payload runs well on a VPS, Docker container, or Kubernetes cluster. A modestly priced VPS can comfortably serve a Payload instance handling meaningful production traffic, which keeps infrastructure costs low for small and mid-size projects.

Strapi Hosting

Strapi is a traditional Node.js server. It runs on any platform that supports Node: VPS, Docker, Railway, Render, DigitalOcean App Platform. It does not run well on serverless platforms, because it relies on a persistent process rather than short-lived functions; deploying it to Lambda isn't recommended.

Strapi Cloud handles managed hosting, but its pricing is much higher than self-hosting on a modestly priced VPS.

For teams comfortable managing infrastructure, both are straightforward to self-host. If you're already invested in Next.js and Vercel, Payload's integration is a strong advantage. We cover deployment strategies in detail on our headless CMS development capabilities page.

TypeScript Support

Payload is TypeScript-native. Your config files are TypeScript, your generated types match your collections exactly, and the local API returns fully typed responses. Add a field to a collection and the TypeScript compiler immediately tells you everywhere that field is, or isn't, being used. It's the kind of DX that's genuinely hard to go back from once you're used to it.

// Auto-generated types from Payload config
import type { Post } from '@/payload-types'

// Full type safety
const post: Post = await payload.findByID({
  collection: 'posts',
  id: '123',
})
console.log(post.title) // ✅ typed
console.log(post.nonExistent) // ❌ TypeScript error

Strapi 5 has improved TypeScript support with auto-generated types via strapi ts:generate-types, but TypeScript isn't the main authoring language. Many Strapi plugins and examples are still JavaScript-first. The TypeScript experience is functional but not as tight. You'll feel the difference daily if you lean hard on your IDE's type hints.

For teams building with Next.js or other TypeScript-heavy frameworks, Payload's type safety removes an entire category of bugs before they ever hit production.

When to Choose Payload vs Strapi

Choose Payload When:

  • You're building with Next.js and want a unified codebase
  • Your team is TypeScript-proficient and values type safety
  • You need complex access control without paying for Enterprise
  • You want the local API performance advantage
  • You're building a page-builder or layout-driven site
  • You need self-hosted with full features at $0 license cost
  • Live preview is a requirement for your editorial team

Choose Strapi When:

  • You need to serve content to multiple frontends (mobile, web, kiosk)
  • Your team includes non-technical content strategists who need GUI schema editing
  • You want a large plugin ecosystem with pre-built integrations
  • You're using a non-Next.js frontend framework (Astro, Nuxt, SvelteKit)
  • You prefer a more traditional decoupled architecture
  • Your team already has Strapi expertise and retraining doesn't make sense

The Social Animal Perspective

We migrated SleepDr.com from WordPress to Next.js 15 and Payload CMS, building a HIPAA-safe architecture with medical schema across 20 city landing pages in four languages. Lighthouse performance rose from 35 to 94 (case study). That project shapes our default recommendation: for Next.js frontends, Payload's local API, type safety, and zero-cost feature set make it the stronger technical choice. Strapi remains a solid option for teams that need one CMS to serve multiple frontends, or that already have deep Strapi expertise worth keeping.

If you're evaluating CMSs for an upcoming project, reach out for a technical consultation, or review our pricing for headless development engagements.

FAQ

Is Payload CMS really free for production use?

Yes. Payload is MIT licensed, and every feature, including access control, localization, versions, live preview, and the admin panel, is available at no cost when self-hosted. Payload Cloud is a paid managed hosting option, but it's entirely optional. There are no feature gates in the open-source version.

Can Strapi work with Next.js?

Yes. Strapi works with any frontend framework via its REST or GraphQL APIs. It runs as a separate server, though, so you'll have HTTP overhead on every data call. Payload's advantage is the local API that removes this overhead when both CMS and frontend share the same Next.js process.

Which CMS is better for non-technical editors?

Strapi generally offers a more intuitive admin panel for non-technical users, mainly because of its Content-Type Builder GUI and polished editorial interface. Payload's admin has improved a lot in v3 and includes features like live preview that editors appreciate, though its initial learning curve is slightly steeper. Editors generally become comfortable with either interface within a similar timeframe.

Does Payload CMS support GraphQL?

Yes. Payload supports REST, GraphQL, and the local API. GraphQL is available as an official plugin (@payloadcms/graphql). For Next.js projects, though, the local API is almost always the better choice. It's faster and fully typed without needing a GraphQL code generator.

Can I migrate from Strapi to Payload?

You can, but it takes real effort. There's no automated migration tool. You'll need to recreate your content types as Payload collections, write a data migration script to move content, and rebuild any custom plugins or integrations. For complex projects, budget several weeks for a full migration.

Which CMS has better performance at scale?

Payload's local API gives it a measurable edge in same-process architectures. For decoupled deployments where both run as separate services talking over HTTP, the performance gap narrows a lot. Both handle thousands of concurrent requests comfortably on modest hardware. The bottleneck is almost always the database, not the CMS application layer.

Is Strapi's community larger than Payload's?

Yes. Strapi entered the market earlier and has built a larger overall community, reflected in a bigger GitHub star count (see Strapi and Payload on GitHub) and a larger plugin marketplace. Payload's community is smaller but growing quickly, especially within the Next.js ecosystem, and both projects keep active Discord communities.

Which CMS should I choose for a headless e-commerce project?

For headless e-commerce, Payload's built-in Stripe plugin and function-based access control make it easy to build customer-specific pricing, multi-tenant catalogs, and complex permission rules. Strapi can handle e-commerce use cases through community plugins, but advanced access patterns usually need its Enterprise tier. If your frontend is Next.js, Payload is generally the stronger choice.

Key takeaway:

Payload embeds in Next.js; Strapi stays a separate Node server. Choose by team structure.