You’ve got Payload and Directus on the shortlist, and on paper they look close. Both can be self-hosted, both put an admin panel and REST and GraphQL APIs on top of a database, and both cost nothing to start. The difference is where the schema lives. In Payload, you define it in TypeScript and the database follows. In Directus, the database comes first and the admin reads whatever it finds.
If you’re building a new TypeScript or Next.js app and want every data-model change reviewed in a pull request, choose Payload. If your SQL database already exists and other systems write to it, or people outside engineering need to change the data model, choose Directus.
For the wider field, see our overview of Payload CMS alternatives. For Payload on its own, see our guide to Payload’s features, architecture and costs.
- Payload CMS vs Directus at a glance
- Where does the schema live?
- Do you already have a database?
- How does each one run?
- Which one keeps your schema in code review?
- What ships built in, and what do you build?
- Which databases does each support?
- Who works in the admin?
- What does each cost, and what does the licence allow?
- When Payload is the better choice
- When Directus is the better choice
- How to decide
- Payload CMS vs Directus: common questions
Payload CMS vs Directus at a glance
| Payload | Directus | |
|---|---|---|
| Where the schema lives | TypeScript config, database follows | The database, admin and API follow |
| Existing database | Keeps tables it doesn’t manage; its admin and APIs cover only what you model | Introspects existing tables and relationships |
| How it runs | As a Next.js app; your front end can share it or call its API | As its own Node service |
| Databases | MongoDB, Postgres, SQLite | PostgreSQL, MySQL, MariaDB, MS SQL Server, OracleDB, SQLite, CockroachDB |
| Licence | MIT | MSCL-1.0, source-available; each version becomes GPL-3.0 after four years |
| Self-hosted licence cost | $0 | $0 on Core (3 seats, 25 collections) or under the Open Innovation Grant; Team $499 a month billed annually |
| Managed hosting | Payload Cloud: new projects currently paused | Directus Cloud, $99 a month on Core and Team |
| Automation | Hooks and the Jobs Queue, in code | Flows, a visual builder |
| Dashboards | Custom admin views in React | Insights, no code |
| Realtime | None built in | WebSockets and GraphQL subscriptions |
| AI and MCP | Official MCP plugin | MCP server and AI Assistant built in |
| Admin UI | React, any component replaceable | Studio, Vue 3 |
| Types | Generated from the config | A schema type you write for the SDK |
| Best for | New TypeScript and Next.js apps where the schema is code | Existing or shared SQL databases, and mixed teams who change the model in the admin |
Where does the schema live?
In Payload, the schema lives in your code. You define collections and fields in the Payload config, and Payload builds the database tables, the TypeScript types and the admin panel from it (Payload database docs). In Directus, the schema lives in the database. Directus maps each table to a collection and each column to a field, and it reads tables it didn’t create as well as the ones it did (Directus data model docs).
For example, say you need a region field on your products. In Payload, a developer adds the field to the products collection, creates a migration, and the change reaches production through a pull request (Payload migrations). In Directus, anyone with permission to edit the data model adds the field in the Studio, and because Directus fields are database columns with metadata, the column is created when they save (Directus fields).
In practice, this decides who can change your data model and where that change gets reviewed, in a pull request or in the Studio’s permissions.
Do you already have a database?
If you do, Directus is built for it. Point Directus at an existing database and it introspects the tables and relationships already there, then serves them through its API and Studio (Directus data model docs).
Payload expects to own its schema. In development, Payload’s Postgres adapter pushes the config’s schema straight to the database (Payload migrations), and its docs note that by default Payload drops the current database schema (Payload Postgres docs). You can keep tables Payload doesn’t manage by declaring them in the adapter’s beforeSchemaInit hook, and Payload’s docs suggest generating those declarations with Drizzle’s introspection. Those tables stay outside Payload’s admin and APIs until you model them as collections. A tool that would generate Payload collections from an existing database is an open feature request on Payload’s GitHub, filed in January 2024 and still open in September 2026 (discussion #4919).
For example, picture a Postgres database that a billing service writes to and a reporting tool reads from. Directus can sit on top of it as it is and give your team a Studio for those tables. Payload can share that database, but only the tables you model as collections appear in its admin, and the rest stay with the billing service.
By Directus’s own account, you can point Directus at a database Payload created and it will read the schema, but Payload won’t pick up tables that exist outside its config (Directus vs Payload). So a database that other services already use points to Directus, and a new app with a database of its own points to Payload.
How does each one run?
Payload’s admin panel and APIs run as a Next.js app, and Directus always runs as its own Node service. Since Payload 3.0, Payload installs into a Next.js app’s /app folder (Payload installation). Your front end can live in that same app and read content through the Local API without an HTTP request (Payload Local API), or it can be one or more separate apps, in any stack, calling Payload’s REST API or GraphQL API. With Directus, every client, your front end included, calls the service over REST, GraphQL or WebSockets (Directus vs Payload).
For example, a Next.js site built in the same app as Payload reads a product through the Local API as a typed function call, and a mobile app in another stack reads the same product over REST.
In other words, the number of front ends doesn’t separate the two. Both serve any number of clients over HTTP, and Payload adds the Local API for code that shares its app.
Which one keeps your schema in code review?
Payload does, because its schema is TypeScript. Payload generates TypeScript types from your config with one command, so the code that reads your data is typed against the same fields as the schema (Payload type generation). A schema change is a migration file committed next to the code that depends on it (Payload migrations).
Directus handles change control through its instances. Each environment is a separate Directus project, and schema changes move between them through the Schema API, which takes a snapshot of one instance, diffs it against another and applies the difference, for admin users only (Directus Schema API). Directus’s own guide says schema changes should start in development and be promoted from there (promoting changes between environments).
For example, rename a field in Payload, regenerate the types, and every line of code that still reads the old name fails the type check before it ships. In Directus, the rename takes effect in the instance where it’s saved, and the SDK’s types change when you update the schema type you pass to it (Directus SDK).
What ships built in, and what do you build?
Directus ships more of the operations layer in the box. Flows is a visual automation builder that runs triggers and operations on data changes, schedules or webhooks, with a log for every run (Directus Flows). Insights builds dashboards without code (Directus Insights). Realtime subscriptions run over WebSockets with the connecting user’s permissions (Directus realtime). The Studio includes an AI Assistant on every plan (Directus pricing), and Directus has had an MCP server built in since v11.12 (Directus MCP).
Payload covers the same jobs in code. Hooks run before or after any operation on a collection (Payload hooks). The Jobs Queue moves slow work off the request and runs recurring tasks on a cron schedule (Payload Jobs Queue, schedules). The official MCP plugin connects your collections to AI tools, with find, create, update and delete allowed or blocked per collection (Payload MCP plugin). Payload has no built-in realtime layer, so live updates mean adding your own WebSocket service.
Directus’s comparison says Payload has hooks alone and no native MCP server (Directus vs Payload), but Payload’s Jobs Queue and MCP plugin docs show both.
For example, say you want an email to the account manager whenever an order over a set value lands. In Directus, an operations lead can build that as a Flow with an event hook trigger, a condition operation and a send email operation (Flow triggers, Flow operations). In Payload, a developer writes an afterChange hook that queues a job, and the job’s task sends the email and retries if it fails (Payload tasks).
On Payload, a Flows-style builder is something you build or adopt as a plugin, and we built one. Our workflows plugin is packaged with the app, attaches to any collection’s create and update events, and runs its steps on Payload’s jobs queue. Its nine step types send an email, wait a set number of minutes, hours or days, call a webhook, create, read or update a record, wait for input, branch on a condition, and loop. We built it from what clients kept asking for, and chained together the steps cover most operational automations, with hand-written hooks for the rest.
In practice, if operations people will build their own automations and dashboards, Directus gives them the tools. If you want automation versioned and tested with the rest of your code, Payload keeps it there.
Which databases does each support?
Directus supports more SQL engines. As of September 2026, its list is PostgreSQL, MySQL, MariaDB, MS SQL Server, OracleDB, SQLite and CockroachDB (Directus requirements). Payload’s official adapters cover MongoDB, Postgres and SQLite (Payload database docs). Payload’s comparison page says Directus offers one SQL option (Payload vs Directus), but Directus’s documentation lists all seven.
For example, an organisation standardised on SQL Server or Oracle can run Directus on the database it already licenses and backs up, and Payload can’t connect to either. A team on MongoDB gets the reverse. Payload’s MongoDB adapter stores each Payload document as a single MongoDB document, and Directus supports SQL databases only.
Who works in the admin?
Payload’s admin panel is built with React and ships as part of the same Next.js app, and you can replace its default components, or add your own, through the Payload config (Payload custom components). It’s shaped around the content and data model your developers defined. The Directus Studio is built with Vue 3 and works as a shared workspace where editors, operations staff and data people use the same interface, and people with permission can change the data model there too (Directus vs Payload).
For example, a content editor and an operations lead usually need different screens. In Payload, a developer builds each one as a custom view, a React component that replaces a built-in view or adds a new one, and ships it with the app (Payload custom views). In Directus, the operations lead can assemble their own Insights dashboard from panels.
If your real question is how the editing experience compares with a familiar publishing tool, our Payload CMS vs WordPress comparison covers that ground.
What does each cost, and what does the licence allow?
Payload is MIT licensed and free to self-host (Payload on GitHub). Directus is source-available under Monospace’s MSCL-1.0 licence, first released with Directus v12.0.0 on 10 June 2026 (Directus releases), replacing the BSL-1.1 licence it had used since April 2023 (licence history).
The MSCL lets you use, modify and host Directus for any purpose except a Competing Use, which means offering the software to others in competition with Directus’s own paid offerings (Directus licence). It explicitly allows professional services, including deploying or hosting Directus for a client. Each version also becomes available under GPL-3.0 on the fourth anniversary of its release. It isn’t open source in the OSI sense, and Directus’s own comparison says so (Directus vs Payload).
As of September 2026, Directus prices self-hosted and cloud use like this (Directus pricing):
| Directus plan | Price per month | Seats | Collections |
|---|---|---|---|
| Core | $0 | 3 | 25 |
| Team | $499 billed annually, $599 month to month | 10 with SSO, then $50 each | 50, expandable to 100 |
| Enterprise | custom | custom | 200+ |
Organisations under $5M annual revenue and 50 employees can apply for the Open Innovation Grant, which gives full access free when self-hosted. Directus Cloud is a $99 a month hosting add-on on Core and Team (Directus pricing).
Payload has no seat or collection tiers. Payload Cloud is currently paused for new projects (Payload Cloud update). Payload sells its paid tier under an Enterprise licence (Payload’s business model), with dedicated support, SSO, publishing workflows and audit logs (Payload Enterprise).
For example, a company of 60 people with 13 editors who need to log in is outside the grant and over Core’s three seats. On Directus Team, that’s $499 a month plus three extra seats at $50 each, or $649 a month on annual billing. On self-hosted Payload, the same team pays no licence fee, though SSO would sit in Payload’s Enterprise tier.
Hosting, backups and upkeep are yours to pay for on both when you self-host. What self-hosting Payload costs in practice is in our breakdown of Payload’s running costs.
When Payload is the better choice
Payload fits when the backend is part of an application you’re building. It’s the stronger choice when:
- You’re starting a TypeScript app, usually on Next.js, and the backend belongs inside it.
- You want schema, access rules and automation reviewed as code in pull requests.
- Auth, product logic and content should live in one codebase.
- Your policy requires an OSI-approved open-source licence.
- You run MongoDB.
We’ve built on Payload since 2025, and as of September 2026 we manage 27 Payload codebases, all built on Next.js. Earlier, we shipped on platforms such as WordPress and Directus. Before choosing Payload, we looked at Directus again, alongside Sanity and Strapi. Payload’s config-driven TypeScript fitted the way we build with AI coding agents. We kept Payload’s official docs inside our repos, next to the setup we’d written to guide those agents.
When Directus is the better choice
Directus fits when the data comes first and the backend wraps it. It’s the stronger choice when:
- Your SQL database already exists, or other services write to it.
- You run MySQL, MariaDB, MS SQL Server, OracleDB or CockroachDB.
- People outside engineering build automations, dashboards and data-model changes themselves.
- You need realtime subscriptions without running another service.
How to decide
Three questions settle most projects:
- Does the database already exist, or do other systems write to it? If yes, start with Directus.
- Who changes the data model? If it’s developers working in pull requests, choose Payload. If it’s people working in the admin, choose Directus.
- Which database do you run? A SQL engine Payload has no adapter for points to Directus. MongoDB points to Payload.
If none of the three settles it, compare licences. Payload is MIT with no seat limits, and Directus charges above its grant and Core limits.
If neither backend fits, our full list of Payload CMS alternatives covers the rest of the field. Payload CMS vs Strapi covers the other self-hosted Node option, its plugins and its upgrades, and Payload CMS vs Sanity covers moving to a managed platform.