Directus vs Payload CMS

Directus and Payload both combine structured content, an editing interface and APIs. Both can support a website, an application or several channels sharing the same information. Their differences become clearer when you follow a change from the data model through to an editor’s screen.

In Directus, administrators can configure collections, fields and relationships in Studio. In Payload, developers describe those structures in TypeScript and ship them with the application. Either approach can produce a straightforward experience for the people publishing content. The choice matters most to the people extending that experience and keeping it consistent across environments.

This comparison covers the current Directus v12 licensing model and Payload’s open-source core, identifying separately scoped features where relevant. It is a documentation-based evaluation. The scenarios below are illustrative, with a checklist for testing the same choices on your own project.

Data modelling and the existing-database decision

Directus can inspect existing SQL tables and relationships, then expose them through its REST and GraphQL APIs. Studio needs additional metadata to turn that structure into useful forms. Permissions also need configuring before ordinary users can access it. There are compatibility limits: the current collections documentation identifies composite primary keys as unsupported.

This is valuable when your product catalogue or operational records already have an established schema. You can assess the editing layer without first proposing a new home for every record. Begin with a copy of the database and inspect identifiers, relationships and writes made by other applications. A shared database deserves an explicit agreement about which system may change which fields.

Payload starts from collections, globals and fields in its config. A collection might hold articles, products or offices; a global might hold navigation. Blocks define repeatable page sections, while relationships connect records. The same model shapes the admin interface and APIs.

Its official database adapters cover PostgreSQL, MongoDB and SQLite. That does not make an arbitrary existing PostgreSQL database ready for Payload. Budget for mapping and migration when the existing tables follow a different model. Payload is particularly attractive when the content schema can evolve alongside the rest of a TypeScript application.

Moving changes between environments

Directus also supports a version-controlled development process. Its v12.3 CLI can pull configuration into JSON, show a diff and push changes to another instance. The Schema API provides snapshot, diff and apply operations for the data model. Describing Directus as incapable of schema review in Git would be wrong.

Payload configuration is already application code. With a relational adapter, database migrations carry the corresponding database changes through environments. In either system, distinguish a structural change from moving records and files. Renaming a field, copying translated content and restoring a complete site are different operations; the release plan should say how each is verified and reversed.

What editors actually get

Directus provides configurable forms and layouts in Studio. Its Live Preview can display the frontend beside an item. Its Visual Editor lets editors navigate the rendered site and edit connected content in context. Developers integrate the frontend library and configure the Studio module first.

Payload’s Live Preview displays the frontend inside the admin and can reflect unsaved edits. Developers connect that frontend to the preview data. Blocks can let editors assemble pages from approved sections, and custom React components can make a specialised task easier to complete.

These features deserve more than a yes/no row. Ask an editor to find the right page, change a shared testimonial, add a permitted section and check the mobile layout. Can they tell whether an edit affects one page or twenty? Can they see an unpublished translation? Are the field names recognisable without a developer explaining them?

For both platforms, the answer depends on the implementation. A good content model gives editors meaningful choices and protects the design. Neither a live preview nor a visual-editing overlay automatically supplies a complete free-form website builder. Payload’s enterprise page lists a separate Visual Editor as coming soon. Keep that roadmap item separate from core Live Preview and obtain availability confirmation before making it a delivery requirement.

Drafts, permissions and approval

Directus content versioning lets teams develop alternate or draft versions and promote the chosen content. Payload versions add history, differences and restoration when enabled; drafts and autosave are configured alongside them. Decide what editors can restore and how long history must remain available.

A saved version does not by itself establish a legal-review process. Write down who may edit, approve and publish, whether two people must be involved, and whether approval is invalidated by a later change. Check that these rules apply through APIs as well as through buttons in the admin.

Directus access policies support item and field restrictions. Multiple applicable policies can expand access: field permissions are combined, and item rules can be joined with OR. A restrictive-looking policy therefore needs testing alongside the other policies a person inherits. Match required policy features to the quoted plan.

Payload access functions express collection and field rules in code. A useful review checks both allowed and forbidden actions: a contributor can update a draft but cannot publish it, and a regional editor cannot read another region’s private records. For server-side calls, the Local API defaults to bypassing access control; calls acting on behalf of users need the appropriate user context and overrideAccess: false.

For either platform, specify identity integration and audit retention separately. Payload advertises SSO and publishing workflows as enterprise offerings. Custom workflows are another possible implementation, with their own scope and tests. Do not equate core access functions or document history with every requirement on a procurement checklist.

Localization and integrations

Directus represents translated content through related translation records; its translation tooling can create the associated collections and fields. Payload’s field-level localization lets a shared record contain localized values and configured fallbacks. These are different modelling approaches to a similar editorial need.

Take a product with one shared SKU, translated titles, regional images and a different release date for each market. Define which values belong to the product, which belong to a language and which belong to a market. A locale is not always a market. Then test incomplete translations and independent publication. The website still needs correct locale URLs, language alternates and a deliberate fallback policy.

For integrations, Directus offers visual Flows: events, schedules or webhooks can start a sequence of operations. Payload offers hooks and a jobs queue for code-defined background work. A form submission might create a record, notify a team and send data to a CRM in either implementation.

The practical questions are what happens when the CRM is unavailable, how failed work is retried, and whether a repeated event creates duplicates. An integration diagram should name credentials, responsible systems and failure handling. The presence of a webhook or an AI connector establishes a connection mechanism; it does not prove that the complete business process works.

Licensing and a useful cost comparison

Older Directus comparisons often stop at its former BSL revenue threshold. Directus v12 uses the Monospace Sustainable Core License, with current plan entitlements and a separate grant programme. Check the version being procured and the applicable terms rather than carrying forward an older summary.

As checked on 25 September 2026, the pricing page lists Core at no software charge with 3 Studio seats, 25 collections and 5 Flows. Team is $499 per month with an annual commitment, or $599 monthly; hosting is an additional line. Directus Cloud is listed as a $99 monthly add-on for Core and Team. Confirm tax, billing, allowances and support in the actual quote.

The Open Innovation Grant clarification is important for agency projects. Eligibility concerns the organisations using Studio: annual revenue below $5 million and fewer than 50 employees. If a client also uses Studio, its eligibility matters. The grant is perpetual while its conditions remain satisfied; it is not an unconditional exemption after a business grows. Application users who do not use Studio are treated differently, and environment activations have their own rules.

Payload’s core is MIT-licensed, with no core software-plan charge per editor or collection. Enterprise features and support should be identified separately. Its Cloud notice says new projects are paused, while existing Cloud projects continue. A new implementation can use compatible managed infrastructure and a delivery partner responsible for operations. Editors do not need to operate that infrastructure.

For a useful three-year estimate, price the same requirements on both sides:

• Initial content modelling, frontend work, editorial setup and migration.
• Required licences, environments, integrations and support coverage.
• Hosting, database, media storage, traffic, backups and monitoring.
• Ongoing changes, upgrades, security response and restore testing.
• A realistic growth case: additional brands, editors, collections and locales.

Record assumptions beside each amount. Avoid multiplying a starter-plan price into a forecast for a very different deployment. Our CMS quote-comparison worksheet provides a way to line up those scopes.

Two practical selection scenarios

An established catalogue with several consuming systems

Imagine a distributor whose SQL database already holds products, suppliers and classifications. Operations staff need better editing tools, and several applications depend on the existing relationships. They want to preserve that data model.

Directus is a strong candidate. A proof of fit would connect a database copy, configure one complex product form and expose a restricted API to a downstream application. The deciding evidence is whether the schema is compatible and the editors can do their work safely. Licence eligibility and collection allowances belong in that evaluation before expansion.

Payload becomes more compelling if the project includes a deliberate redesign of the product model and substantial new application logic in TypeScript. That would justify assessing a migration. A CMS preference alone would not justify disturbing a working shared database.

A multilingual Next.js product and marketing site

Imagine a software business combining product documentation, campaign pages and customer-specific resources. Its developers already maintain a Next.js application. Editors need approved page sections, regional content and clear review permissions.

Payload is a strong candidate because those collections, access functions and page renderers can evolve in the same repository. A delivery partner can provide the hosted service while editors work in the tailored admin. The evaluation should demonstrate one complete campaign page and one protected customer resource, including preview, publication and API access.

Directus could still be the better fit if frequent visual model changes and Flow configuration by trained administrators outweigh the benefits of keeping those definitions in application code. Ask the people making those changes to perform them in both prototypes. That is more informative than treating either approach as universally easier.

Migration and the exit path

Owning a database reduces dependence on a hosted content service, but moving between these products still takes work. Directus permissions, Flows, interface configuration and translation relations need equivalents. Payload access functions, blocks, hooks and rich-text structures are also application-specific.

Inventory record IDs, relationships, rich text, files, versions, languages and users. Decide what history must be retained and whether account migration needs a reset or a separate identity plan. A database copy alone will not recreate either editorial application.

For an existing website, preserve the URL inventory and useful content. Verify redirect targets, canonicals, metadata, structured data and translated routes against the old site. Reconcile record counts and relationship integrity before switching traffic, and keep a rollback path. These are acceptance conditions for a migration, regardless of which platform wins the comparison.

A short evaluation your team can run

Use the same content sample and roles in both systems. Ask for these demonstrations before approving the implementation:

1. Model an item with a relationship, reusable section, localized text and private field. Show how the change reaches staging.
2. Have an editor create a draft, preview it and submit it for review without elevated permissions.
3. Attempt a forbidden read and publish operation through the API as that editor. Record the result.
4. Publish an approved change, verify the intended frontend and cache update, then restore the previous content.
5. Trigger an integration failure and show how the operator discovers and recovers it.
6. Export the example with its relationships and files. Explain what another system would need to reconstruct it.
7. Attach the licence and operating quote for the same users, data model and environments used in the demonstration.

Record the result, configuration required and remaining implementation work. This makes the choice reviewable by editors, developers and procurement together. It also turns the winning demonstration into useful acceptance criteria for delivery.

A note on our position

WAYF is an official Payload partner and top contributor. We often choose it for tailored publishing tools and TypeScript applications. Directus deserves serious consideration when a compatible existing database and visual configuration are central to the brief. We can help assess the content model, editorial workflow and migration scope before you commit to either direction.