Payload

Why it's ranked here

The verdict is positive. The codebase splits cleanly into independent packages for each database and each framework integration (Postgres, MongoDB, SQLite, a Next.js adapter, a GraphQL layer), which is what real multi-backend support looks like rather than one adapter bolted on. Access control defaults to deny and combines a top-level policy with per-document rules using explicit AND logic. The GraphQL layer ships query complexity limits and disables introspection in production automatically. Password hashing already has a migration path built in for rotating to a newer scheme without breaking existing logins, a detail that only shows up in software that has already run in production.

What's good

The Local API is a genuine advantage: server code can call collection operations as plain function calls, in-process, with full type inference, no HTTP round trip needed for the common case of reading your own data. Access control is unusually granular, covering not just collections but individual fields, and functions receive the current locale so behavior can vary by region. The official plugin set already covers Stripe billing, multi-tenancy, SEO, search, and import/export, so common product needs don't require custom integrations. Deploy templates exist for both Vercel and Cloudflare with database and storage wired up automatically.

Tradeoffs

The stateless JWT option cannot be revoked once issued and stays valid until it expires even after a password change, a real footgun for a team that reaches for it without reading the fine print. The top-level access-control helper explicitly does not extend to field-level rules, custom endpoints, or direct database adapter calls, so teams still have to write those checks by hand. The Local API skips all access control by default, so server code that forwards user input into it without explicitly opting back in can bypass permission checks entirely.

How to use it well

Reach for this when a Next.js project needs a real content or data backend and you want one deployable unit instead of a separate CMS service to run and pay for. Start from the official starter template rather than a blank config: it demonstrates drafts, live preview, and the block editor together, which is faster than assembling those patterns from documentation alone. Lean on the official plugin set for common needs like billing or search instead of writing custom integrations. It fits less well when the content layer must be shared across services written in different languages, since its strongest advantages are JavaScript-side.

Observed

Language

TypeScript, distributed as an npm package with separate framework and database adapter packages under the @payloadcms scope

Packaging

pnpm/turbo monorepo split into packages by concern: core, Next.js adapter, database adapters, GraphQL layer, rich text editor, CLI scaffolder

Installation

Scaffolded via a CLI generator or added directly as a dependency inside an existing application

Interfaces

In-process Local API, auto-generated REST API, and auto-generated GraphQL API, all built from the same collection config

Database adapters

Official adapters for Postgres, MongoDB, SQLite, Vercel Postgres, and Cloudflare D1/SQLite

Deployment targets

One-click deploy templates for Vercel and for Cloudflare Workers with R2 and D1, plus standard self-hosting

Auth strategies

HTTP-only cookies, JSON Web Tokens, and API keys, usable together or independently per collection

Access control model

Per-operation access functions (create/read/update/delete) at the collection, global, and field level, plus an optional top-level policy combined with document-level rules using AND semantics