Directus: a SQL database with generated REST and GraphQL APIs on top

The problem Directus solves is the API layer you keep rewriting

Most teams end up writing the same code twice. Once as a database schema, once as a set of endpoints that expose that schema, and a third time as an admin screen somebody in operations needs to edit a row. Directus takes the position that the schema is the source of truth and everything else should be generated from it. The README describes the product as wrapping any SQL database with a REST and GraphQL API layer and a visual Studio, with APIs generated automatically from your database schema and no configuration required. The intended audience is split in two. Engineers keep control of schema and access. Non-technical colleagues, and increasingly AI agents, work against the live data instead of filing tickets for a new endpoint. That split is the actual product decision, and it is also the source of most of the friction you will hit later.

How the database-to-API layer actually works

The mechanism is introspection rather than code generation you commit. Directus connects to a database you already run, reads its structure, and exposes that structure over REST and GraphQL. The README lists Postgres, MySQL, MariaDB, MS SQL, SQLite, OracleDB and CockroachDB as supported engines. Because the schema lives in your database, the API surface changes when the schema changes, not when you redeploy application code. Permissions sit on top as policies, described in the README as granular down to the field level, applied to humans and AI agents alike. That last point matters more than it sounds. The native MCP server lets Claude, Cursor, ChatGPT or any MCP-compatible tool connect to the data, and the README states that agents operate under the same role-based permissions as human users. Whether that holds in practice depends on how carefully you write the policies, since a field-level grant to an agent is still a field-level grant. The Studio is a management interface built on the same permission layer, so an editor who cannot see a column in the API also cannot see it in the UI. Extensibility runs through custom endpoints, hooks, interfaces and modules, which is where you go when introspection is not enough.

Getting a local instance running

The README does not include an install command block, so the exact bootstrap sequence has to come from the documentation rather than this page. What the README does give you is the deployment surface. There is a one-click Railway template that provisions PostgreSQL, Redis and S3-compatible storage connected over Railway's private network, and Directus Cloud provisions a managed project the README says takes under 90 seconds, bundling database, storage, auto-scaling and a CDN. Self-hosting is explicitly supported alongside cloud. The configuration keys you will care about are not listed in the README, which is a real gap if you are planning a bare-metal install: you will need the docs for database connection variables, storage adapter settings and the admin bootstrap values. Treat the Railway template as the fastest way to see the Studio and the generated API before you commit to anything. The important thing to verify early is that Directus can read your existing schema without a migration step, because that is the entire premise.

The licence is the constraint, not the feature list

The repository license field reads NOASSERTION, and the README explains why. Directus ships under the Monospace Sustainable Core License 1.0, described as a source-available licence derived from the Fair Core License. Source-available is not the same as open source, and the practical consequences are spelled out. Organisations under $5M in annual revenue and 50 employees can use it free under the Open Innovation Grant, which the README says issues a key in minutes. A free core tier exists for everyone to explore and build on without a commercial licence. Above those thresholds, using advanced or enterprise features requires a commercial licence. If your organisation is near either boundary, or if your procurement process requires an OSI-approved licence, this is the point where the evaluation ends. I am not giving legal advice, and the thresholds as written combine revenue and headcount, so the reading of your own situation belongs with whoever signs your contracts. Note also that the $5M and 50 employee figures appear in the README and on the licence page, not in any machine-readable metadata.

Where the generated-API approach breaks down

Introspection is a trade-off, not a free win. When the API is derived from the database, your database schema becomes a public interface. Renaming a column is no longer a private refactor, it is a breaking API change, and the Studio's field configuration is part of that surface too. Teams that iterate on their data model weekly will feel this immediately. There is a second failure mode in the permission layer. Field-level policies are powerful and also easy to get wrong, because a policy that is too broad leaks data through the API and through any connected MCP agent at the same time. The README positions governed-by-default as the answer, but the governance is only as good as the policy you wrote. A third limitation is engine support. The README names OracleDB and CockroachDB among the supported databases, but it gives no detail on how complete that support is, and no compatibility matrix. If you run something outside the listed engines, or an unusual version of one inside it, that needs checking against the docs before you plan around it.

What you give up compared with a code-first framework

The obvious alternative is a code-first backend framework such as Strapi or a hand-rolled API on top of your database driver, where content types are defined in config or code and the database is generated from that definition instead of the other way round. The difference in approach is directional. Directus reads your schema and produces the API. A code-first tool takes your content model and produces the schema. If your database already exists, holds data you cannot easily migrate, and is managed by a DBA who will not hand over control, Directus fits and the code-first tools fight you. If you are starting from nothing and want the schema to be a build artefact you can throw away and regenerate, the code-first direction is cleaner, because the schema is disposable by design. The second real alternative is writing the REST layer yourself. You get exactly the endpoints you want and no licence questions, and you pay for it every time a stakeholder wants a new field visible in an admin screen. Directus is a bet that the second cost is larger than the first.

Maintenance, upgrades and what the release cadence implies

The release history shows v12.3.1 in August 2026, v12.3.0 a week earlier, and v12.2.0 in late July. That is a steady minor-release cadence with patch releases following close behind, which tells you upgrades arrive often and you should expect to move. The repository is not archived and the default branch is main. Because Directus sits between your database and every consumer of it, an upgrade is not a library bump: it can change API behaviour, Studio behaviour and permission semantics at the same time. The README offers no upgrade guide or migration notes, so the changelog and the docs are where that work lives. On the licence side, the ongoing cost is the commercial licence once you cross the thresholds, plus the Open Innovation Grant key if you qualify for it. Budget for the upgrade cadence as recurring work rather than a one-off, and pin a version you have actually exercised against your own schema before you let a minor release into production.

Who should adopt Directus and who should walk away

Adopt it if you have a SQL database you intend to keep, a team that includes non-engineers who need to touch the data, and a licence situation that fits under the Open Innovation Grant or a commercial agreement you are willing to sign. The generated API and the shared permission model are the payoff, and they compound as the number of consumers grows. Walk away if you need an OSI-approved licence, if your organisation is above the $5M and 50 employee thresholds and you are not buying, or if your schema changes faster than you can version an API. The thing to verify first is not a feature. It is whether Directus can attach to your existing database as-is, because if it cannot, the entire premise of the product evaporates and you are left comparing it to a conventional CMS on features alone, which is a comparison it is not trying to win.

Editorial conclusion

Adopt Directus when you already have a SQL schema you intend to keep and you want the API and admin surface derived from it rather than defined in application code. Skip it if you need an OSI-approved licence, if your organisation exceeds the $5M revenue and 50 employee thresholds without buying a commercial licence, or if your data model changes shape weekly. Before committing, check the licence page against your own numbers, confirm your database engine appears in the supported list, and decide whether you need the OracleDB or CockroachDB paths at all.

Official sources

1. directus/directus on GitHub
2. Issues
3. Project website
4. README
5. Releases