Directus vs Payload: which headless CMS to choose

Directus or Payload: when each one fits

Choose Directus when your content already lives in a SQL database you need to keep, or when non-developers will edit content every day and need a management interface without writing code. Directus connects to an existing database through the DB_CLIENT setting and supports PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB, then generates REST and GraphQL APIs from the schema and provides Studio for teammates. Choose Payload when your team builds in TypeScript, wants the CMS defined in code alongside a Next.js application, and is comfortable with MongoDB, PostgreSQL or SQLite as the data store. Payload is MIT licensed and installs directly into an existing Next.js /app folder, so the schema, access rules and admin panel live in the same repository as the front end.

The decision turns on four questions. First, is there an existing database that must stay the system of record, or will the CMS own its data? Second, who edits content: developers working in code, or marketers and operations staff who need a no-code Studio? Third, is the front end Next.js, or does it need to be framework-neutral? Fourth, how does your legal team read the Monospace Sustainable Core License 1.0 that governs Directus? The license permits any use except a Competing Use against Monospace's paid offerings, and each version converts to GPL-3.0 four years after release. Have counsel confirm whether your intended use, including any hosted service you plan to sell, falls clearly outside that restriction before you commit.

Payload's own comparison page with Directus makes claims you should treat as vendor claims rather than independent findings. It says Payload's admin UI is built with React while Directus uses Vue.js, that Payload offers visual editing where Directus provides live preview, and that Payload deploys natively to serverless platforms such as Vercel. It also claims Payload is 3x faster than Directus, citing an open-source speed test. Run your own test against your own schema, database and hosting setup, and confirm Payload's MongoDB and PostgreSQL support against your data platform standards. Also check whether your hosting team can run Directus in Docker on your database, since that is the self-hosting path the Directus README describes.

Which scenarios favor Directus and which favor Payload

This table maps common team situations to the platform that fits them better and the condition that makes that true. Read each row as a starting point, then confirm the condition against your own database, team skills and hosting target. The main takeaway is that Directus suits teams whose data already lives in SQL and must stay there, while Payload suits teams whose frontend and content model are built together in TypeScript.

Scenario	Better fit	Condition that makes it hold
Existing SQL database must stay the source of truth	Directus	Directus connects to an existing SQL database through DB_CLIENT, so the schema stays in your database. Confirm that your engine is on the supported list and that your DBA accepts Directus managing its own system tables.
Next.js team building its own frontend	Payload	Payload installs directly into an existing Next.js /app folder and generates TypeScript types from code-defined collections. Holds when the team is comfortable owning content models in code and deploying with the frontend.
MongoDB is a hard requirement	Payload	Payload supports MongoDB, while Directus connects to the SQL engines listed in its configuration documentation. Holds only if MongoDB is a mandated standard; confirm the Payload version you plan to run against your MongoDB version.
Non-technical editors manage content directly	Directus	Directus provides Studio, a management interface built for non-technical teammates. Holds when editors need to manage data without developer tickets; Payload's admin panel is a React build that developers customize.
Serverless deployment target	Payload	Payload's vendor comparison says it deploys natively to Vercel, and its README lists Cloudflare Workers with R2 and D1. Confirm the database you need is supported on that target, since serverless hosting limits what self-managed SQL can do.
Strict open-source licensing requirement	Payload	Payload is MIT licensed, while Directus uses the Monospace Sustainable Core License, which restricts Competing Use. Holds when legal rules out any license with use restrictions; Directus may still fit if your use is not competing with Monospace's paid offerings.
Built-in customer login alongside admin users	Payload	Payload includes built-in authentication for admin and customer users inside the CMS. Holds when the same app must manage both groups; confirm how your identity provider will integrate if you already run one.
Multi-system data platform feeding several applications	Directus	Directus generates REST and GraphQL APIs from the database schema, so several consumers can read one source. Holds when the database is already shared across systems; neither platform replaces a dedicated integration layer if events and workflows are the main need.

How Directus and Payload are built and deployed

Directus sits on top of a database you already run, while Payload is part of the application code you ship. That single difference shapes who owns the schema, how upgrades land and where each platform can be hosted. The cards below take those consequences one at a time.

Database-first schema ownership

Directus connects to an existing SQL database through the DB_CLIENT setting and supports PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB. It generates REST and GraphQL APIs from the schema it finds, so your database team keeps control of tables and migrations. Check who approves schema changes before editors start adding collections in Studio.

Code-first schema in TypeScript

Payload defines collections and fields in TypeScript inside a Next.js /app folder, and it generates TypeScript types from that code. Schema changes travel through the same pull request, review and deployment path as the rest of your front end. The trade-off is that developers, not editors, shape the data model, so plan for engineering time on every content model change.

Database engines for each model

Payload supports MongoDB, PostgreSQL and SQLite, so a team already standardized on MongoDB can keep its document store. Directus targets relational engines only, so Oracle or SQL Server shops can reuse licenses and DBA skills they already have. Confirm your engine and version against each vendor's current requirements before choosing.

Upgrades and Directus Studio

Directus upgrades are applied to a running instance that reads your database, so you test migrations against a copy of production data first. Studio gives non-technical teammates a management interface without a code release for every field. Recent Directus releases include 12.4.0 on September 22, 2026 and 12.5.0 on October 7, 2026, so plan a regular upgrade window.

Payload inside your Next.js app

Payload installs directly into an existing Next.js app, so the CMS, admin panel and front end deploy as one codebase. Teams already running Next.js can keep one build pipeline and one runtime. Confirm how the admin panel and API routes scale in your environment, since they share resources with the site.

Hosting options for each platform

Directus runs in Docker on infrastructure you control or on Directus Cloud, the managed service, so the self-hosted path needs your own database, backups and TLS. Payload deploys to Vercel, to Cloudflare Workers with R2 and D1, or to any host you run yourself. Ask which managed database and storage services your hosting target supports before you commit.

What the Monospace license and MIT license mean in practice

Directus is licensed under the Monospace Sustainable Core License 1.0 (MSCL-1.0-GPL). The license permits any use except a Competing Use against Monospace's paid offerings. Each released version converts to GPL-3.0 four years after its release date, so older versions move toward a standard copyleft license on a fixed schedule. Read the full text in the Directus license and the repository license file before you build a plan around it.

Permitted use: Running Directus internally, for your own applications and customers, is outside the restriction as long as it is not a Competing Use.
Conversion date: Each version carries its own four-year clock, so the conversion date depends on the release you deploy.
Permissive history: Directus changed its license to BSL-1.1 in April 2023 and replaced it with the Monospace Sustainable Core License in 2026, according to the commit history of the license file.
Version pinning: Keeping a record of which version you run tells you which license text governs that deployment.
Vendor-defined terms: Monospace, not the community, defines what counts as a Competing Use, so the boundary can move in ways you do not control.

Before you commit, confirm with counsel which version you will deploy and how the license applies to your use.

Where licensing and lock-in change the total cost

The cost of running either platform is mostly people and infrastructure, not the license fee, and the two platforms spread those costs differently. Neither vendor's price list is supplied for this comparison, so every figure below must come from a written quote and current license terms that you confirm yourself. For Directus, the cost you pay for is the database, the container runtime and the administration of an existing SQL server (PostgreSQL, MySQL, MariaDB, Microsoft SQL Server or another supported engine set through DB_CLIENT), plus any Directus Cloud subscription if you choose the managed service instead. For Payload, the cost sits in a Next.js application that your engineers write, test, deploy and maintain, backed by MongoDB, PostgreSQL or SQLite. Ask each vendor or partner to split its quote by these components so you can compare like with like.

Some costs are one-time and some recur. One-time work includes the initial build, data migration, schema design and, for Payload, the first frontend and collection definitions in TypeScript. For Directus, schema design happens in the database and in Studio, and the cost is usually the modelling and permission work rather than application code. Recurring costs include hosting, database backups and monitoring, license obligations, support retainers and upgrades. Upgrades differ in kind: a Payload upgrade is a dependency and application change that touches your code and its tests, and Payload's v4.0.0 beta line is still in progress, so plan for a migration window. A Directus upgrade is closer to a platform upgrade of a schema-driven service, but you still own the database version and its maintenance. Ask for the upgrade effort per release line and whether it is included in a retainer or billed separately.

Lock-in changes the price of leaving as much as the price of staying. Directus sits on your own SQL schema, so the data stays in a database you already administer, and that makes exit easier to scope, but the Monospace Sustainable Core License and its Competing Use restriction still apply to how you can use and resell it, so confirm with Monospace whether your use is permitted before you commit. Payload's MIT license removes that licensing constraint, but your collections, hooks and access rules live in application code, so an exit means rewriting them. Ask any partner to price a migration out of each platform, not just the build into it, and to state which of the license and hosting costs continue if you stop using a managed service.

How to move content from Directus to Payload, or back

The sequence turns a Directus data model into a Payload configuration without losing content, media or access rules, and it runs both systems side by side until the new frontend is proven. The same order of work applies in either direction.

Inventory collections, fields and relations
The client's content lead and a developer list every Directus collection, field, relation, singleton and custom extension, then record which ones editors use and which are legacy. Directus generates its REST and GraphQL APIs from the database schema, so the schema itself is the starting inventory. The step is done when every collection has an owner, a row count and a status (keep, merge, retire), and the list is approved in writing before any mapping begins.
Map fields to Payload collections and types
A developer translates each Directus collection into a Payload collection defined in TypeScript, matching field types, required flags, localization and relationship direction. Payload generates TypeScript types from its code-defined collections, so the mapping document becomes the source of truth for the new frontend. Fields that Directus stores as JSON or as custom interface options usually need a deliberate target, which should be written down. The step closes when the mapping is reviewed against a sample of real records and each field has a named destination.
Decide whether the SQL database stays
The architect chooses between two paths: keep the existing SQL database and point Payload at a supported engine, or export content into a new database that Payload creates. Payload supports MongoDB, PostgreSQL and SQLite, so a team already on PostgreSQL has a different migration than one on another engine that Payload does not list. Directus reads its schema from an existing database, so in-place reuse is possible only where the schemas can be reconciled. Confirm the engine, backup point and rollback plan with the vendors and the client's DBA before choosing.
Migrate media, users and roles
The team moves files from Directus storage to the target storage, rewrites asset references, and checks that alt text and metadata survive. User accounts and roles are then recreated, because Payload includes built-in authentication for admin and customer users and Directus uses its own role-based permissions. Passwords generally cannot be copied between systems, so the plan should state how users reset credentials and who approves each role. The step is done when a spot check of assets resolves in both systems and each active user can sign in to the target.
Rebuild access rules and hooks
Directus permissions, flows and any custom extensions are rewritten as Payload field-level access control, document and field hooks, and application code. This is the largest manual task, because permission logic rarely maps one to one and Directus RBAC must be reproduced exactly. A security engineer should test each role against a written matrix of allowed and denied reads, writes and deletes. The step closes when the matrix passes in a staging environment and every hook has a documented owner and test.
Run parallel frontends before cutover
The new Payload-backed frontend runs alongside the existing consumers, with Directus still serving production and content synced or dual-written for a defined test window. Developers compare API responses, rendering and preview behavior, and editors work through their daily tasks in the new admin panel. The team should confirm the parallel setup against the client's own change-control rules, because the window length and sync method are decisions for the project, not defaults. The step is done when response diffs are reviewed and signed off by the content owners.
Cut over and keep a reverse path
On an agreed date, the team freezes Directus writes, runs the final content sync, switches traffic to Payload and records the time and checksums of the export. A rollback path is kept until the business confirms stability, because the reverse move, from Payload back to Directus, faces the same schema and permission mapping work. The output is a dated cutover record, a retained Directus snapshot and a list of retired endpoints.

Where Directus and Payload implementation projects run long

The longest delays in a Directus or Payload project come from what each platform expects you to define before anyone sees a working admin. With Directus, the work starts from an existing SQL database: you connect it through the DB_CLIENT setting, then decide how the current schema, roles and row-level permissions map onto what Studio and the generated REST and GraphQL APIs will expose. Teams that skip this mapping often find that tables built for application use do not match how editors expect to work, and that permission rules written for one application quietly grant too much or too little in a shared database. With Payload, the work starts in code: collections, fields, access control functions, localization settings and the Next.js frontend are all written by developers before editors can use the admin panel. Each path is fixed-scope work, and the scope should be agreed in writing before the project begins.

The delays that recur on both platforms follow a similar pattern. Data model rework is the most common, usually triggered when editors ask for a field or relationship that the first design did not anticipate. Permission design takes longer than most plans allow for, particularly where public, customer and internal users need different read and write rights. Editor training is often underestimated because Studio and Payload's React admin panel require different habits for drafts, versions and live preview. Frontend integration is a separate workstream on Payload, since the admin and the site share one Next.js app, and on Directus, since the site consumes the API from another codebase. Database operations also add time: backups, migrations, and the choice between MongoDB, PostgreSQL or SQLite on Payload, or the SQL engine behind Directus, all need an owner. Ask any implementation partner to list these workstreams separately in the written scope, and confirm which ones your team will staff internally.

Before signing, check three points against your own environment rather than assuming them. Confirm which permission model your existing data already relies on and whether it can be expressed in Directus roles and permissions or must be rebuilt as Payload access control functions. Confirm who will own the database after launch, including upgrades to Directus releases or Payload v3 and any v4 beta changes that may affect your code. Confirm how many editors will be trained and on which tools. A fixed-scope plan that names these items, with deliverables and timelines agreed in writing, lets you see where a change request would begin and what it would cost to resolve.

Questions teams ask before choosing Directus or Payload

Can we run Directus for free under the Monospace license?

It may be possible, but the answer depends on how your organization will use Directus, so have counsel confirm it against the license text before you deploy. The Monospace Sustainable Core License 1.0 permits any use except a Competing Use against Monospace's paid offerings, so the key question is whether your product or service competes with those offerings. Read the terms on directus.com/license alongside the repository license file. Your legal team should record the decision, including which entity runs the software and whether you resell or embed it. Each version converts to GPL-3.0 four years after release, so note the release date of the version you deploy. If the boundary is unclear, ask Directus for written clarification and keep it on file.

How much does a self-hosted Directus or Payload build cost?

No supplied source gives a build price, so the cost is a set of components you can estimate yourself. Recurring costs include database hosting, compute, storage, backups, monitoring, patching, upgrades and the engineering time to keep the system running. One-time costs include discovery, data modeling, authentication, access control, integrations, editor training and any evidence you need for an assessment. Costs rise with the number of content types, locales, integrations, environments and compliance controls in scope. Ask any implementation partner for a written scope that lists deliverables, assumptions, your responsibilities and the support window, then compare quotes against the same scope. DeployOpen's engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask who pays for hosting after go-live.

How long does migration from an existing database take?

No supplied source gives a migration duration, so the timeline depends on your data, your integrations and your cutover plan. Directus connects to an existing SQL database through the DB_CLIENT setting and generates REST and GraphQL APIs from the schema, which can reduce modeling work when your content already lives in a supported SQL database. Payload defines collections in TypeScript, so existing content must be mapped into code and loaded into MongoDB, PostgreSQL or SQLite. Drivers include schema cleanliness, the volume of files and attachments, editorial workflows, localization, access rules, existing user accounts and the downstream systems that call your current APIs. Ask for a written migration plan with a data inventory, a test cutover, reconciliation checks and a rollback path before you commit to a date.

Can a developer team run Payload without outside help?

A team with solid Next.js and TypeScript skills can often run Payload in house, but the answer depends on the capacity you can commit to ongoing work. Payload installs into an existing Next.js /app folder, generates TypeScript types from its collections and fields, and can be self-hosted anywhere, so much of the daily work looks like application engineering. The areas that usually need experienced hands include database operations, access control design, security hardening, backup and restore testing, and upgrades. Payload's v4.0.0 line is still in beta at the time of the supplied releases, so plan upgrade testing carefully. Check whether your team can own on-call duties, patch cycles and evidence collection. If it cannot, consider a fixed-scope implementation with a support retainer, which DeployOpen offers alongside its implementation work.

Does MongoDB rule out Directus for our project?

Based on the supplied database list, yes: Directus connects to PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB, and MongoDB is not on that list. If MongoDB is a hard requirement, Payload is the natural option to shortlist, since it supports MongoDB, PostgreSQL and SQLite. Confirm database support with Directus before you decide, because supported databases can change between releases, and check the database configuration documentation for the version you plan to run. Also ask whether the MongoDB requirement comes from the data model or from team familiarity. A relational database may fit your content model well, and Directus can sit on a SQL database your organization already runs, backs up and patches. Ask any partner to document the database, its backup and restore process, and who owns its patching.

Is Payload's 3x speed claim relevant to our project?

It matters only if raw CMS throughput is a real bottleneck for you, and the claim comes from Payload's own comparison page. Payload says it is 3x faster than Directus and cites an open-source speed test, but the supplied facts do not describe the workload, hardware, dataset or versions used. Most content delivery performance depends on caching, frontend rendering, database indexing and network latency, so a faster API layer may not change page load times. Ask for the test repository, the exact versions and the configuration, then reproduce the test with your own content model and query patterns. Include editorial tasks such as bulk edits, previews and publishing, since those can have different bottlenecks. Treat the claim as a hypothesis until your own load test confirms it.

Which editing tools suit non-technical editors, Studio or Payload's admin?

Directus suits teams that want a no-code management interface over data they already keep, because it provides Studio for non-technical teammates. Payload suits teams whose developers will shape the admin panel, since its admin UI is a customizable React panel defined in code. Payload's comparison page also says it offers visual editing where Directus provides live preview, and that Directus uses Vue.js while Payload uses React. Those are the vendor's own claims, so verify them in a working demo. Ask a few real editors to complete their weekly tasks in each tool, including publishing, scheduling, translations and media handling. Record how many steps each task takes and where they get stuck. The result will usually decide the question better than a feature list.

Four risks to test before committing

Directus and Payload differ on four decisions that are costly to reverse after go-live: how the license applies to your product, which database engine you run, how fast each platform releases, and which frontend stack you can use. Each card names what to confirm with the vendor and in your own environment before you commit.

License reading under MSCL

Directus is licensed under the Monospace Sustainable Core License 1.0, which permits any use except a Competing Use against Monospace's paid offerings. Whether your product falls inside that exception decides this risk, especially if you ship a customer-facing product built on Directus. Ask Monospace for a written reading of Competing Use that covers your exact product, then have counsel review it. Payload is MIT licensed, so this specific check does not carry over to it.

Database lock-in to one engine

Directus connects to an existing SQL database and selects its engine through DB_CLIENT, with support for PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB. Payload supports MongoDB, PostgreSQL and SQLite, and its collections are defined in code. Confirm which engine your database team already operates, whether your backup, replication and monitoring tooling covers it, and how you would migrate data if you change engines later.

Upgrade cadence and v4 beta

Directus 12.5.0 was released on October 7, 2026, after 12.4.0 on September 22, 2026. Payload v3.91.0 was released on October 15, 2026, while a v4.0.0 beta line is in progress and v4.0.0-beta.2 was published on October 16, 2026. Fast release lines mean every upgrade is a schema, configuration and extension review on your side. Pin versions, decide which line runs in production, and ask each vendor how long it supports the version you choose.

Frontend coupling to Next.js

Payload describes itself as a Next.js native CMS that installs directly into an existing Next.js app folder, so the admin panel, API and frontend can share one codebase and one deployment. Directus runs as a separate service with its own Studio, so your frontend can use any stack that calls its REST or GraphQL APIs. Confirm that your frontend team will stay on Next.js for the expected life of the site, and that your hosting platform handles a Node.js process serving both admin and public traffic.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Directus vs Payload, we start from your database, licensing position and team skills, then build and hand over a working setup you can run yourself.

How we scope

Confirm which database your organization already runs and whether Directus or Payload must fit it.
Review the Monospace Sustainable Core License against your intended use before any build work starts.
Agree the written scope, deliverables and timeline in writing before work begins, since most engagements are fixed-scope.

How we build

Connect Directus to an existing SQL database through DB_CLIENT, or define Payload collections in code inside a Next.js app.
Configure authentication, roles and field-level permissions so access rules match your organization's model.
Test editing workflows, live preview and hosting targets in your own cloud, data center or air-gapped environment.

How we hand over

Document the architecture, database setup, deployment steps and upgrade path for your own operations team.
Deliver backup and restore procedures so your team can recover content and schema without outside help.
Walk your engineers through permission models, content workflows and the parts of the stack they will maintain.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
Plan version upgrades against each platform's release cadence so your team can test changes before production.
Provide a quote that follows from the written scope, with recurring retainer costs itemized separately from one-time work.

Directus vs Payload