Blog
Directus vs Noma for Structured Content Delivery
March 26, 2026
Directus and Noma both deliver structured content over APIs, but they start from different abstractions. Directus is database-first: it wraps an existing (or new) SQL schema and exposes REST and GraphQL with an admin app on top. Noma is CMS-first: collections and fields are the product model, with REST delivery, project boundaries, translation groups for locales, and AI generation, translation, and assistant built into editorial workflows.
Teams evaluating “structured content” should decide whether they want maximum data-layer control (often Directus) or opinionated content operations with AI in the loop (often Noma).
Quick snapshot
| Dimension | Directus (typical) | Noma |
|---|---|---|
| Core model | Tables and columns mirrored in SQL; Directus metadata layers permissions and UI | Collections and field types (text, richtext, relation, media, group, …) stored in the CMS data model |
| APIs | REST and GraphQL against collections/items | REST per collection: GET /api/{collection} with locale, state, where, exclude, sort, pagination |
| Schema changes | Often migration-driven (SQL); Directus tracks fields | Admin-driven field and collection changes with validation rules aligned to the API |
| Localization | Patterns depend on how you model languages (fields, tables, or translation tables) | Project locales; locale on entries; translation_group_id links variants—see multilingual modeling |
| AI | Integrate via Flows, webhooks, or external services—you orchestrate | Native generation, rewrite, AI translation into draft locales, assistant for content ops |
| Hosting | Self-hosted open source (with commercial options); you operate the stack | Depends on your Noma deployment; product is API-first and AI-native |
What “structured content” means for each
Directus: structure = your schema discipline
Directus shines when:
- Engineers own the database and want transparent SQL and GraphQL for complex reads.
- You need Flows and automation on top of raw data events.
- Content is one of several consumers of the same database.
The tradeoff is governance: without conventions, every team invents a different pattern for locales, soft deletes, and “published” semantics across tables.
Noma: structure = editorial + API contract
Noma shines when:
- Product and marketing need a bounded content model with validation and roles without exposing DB complexity to every editor.
- Frontend teams want stable field keys and documented query behavior—see How to Design Stable Content APIs for Frontend Teams.
- AI should write into named fields and draft locales with translation linkage, not ad hoc columns.
The tradeoff is less arbitrary SQL: you work through the CMS model rather than modeling everything as generic rows.
API consistency and frontend impact
Directus gives powerful query surfaces—especially GraphQL—and teams can tune performance at the database level.
Noma optimizes for predictable REST responses: fields keyed by name, exclude to shrink list payloads, state and locale as first-class query dimensions.
Neither is “more API-first” in the abstract; they differ in who owns query complexity (GraphQL resolvers and DB vs CMS query parameters).
Localization
Directus does not prescribe one multilingual pattern—you might use locale columns, separate tables, or junction patterns. Flexible, but your convention must be documented everywhere.
Noma standardizes per-locale entries plus translation_group_id, with API helpers such as translation_locale on single-entry reads when state matches—reducing ambiguity for apps and AI-generated drafts.
AI in production workflows
Directus can run excellent AI pipelines—often via Flows, custom endpoints, or workers—when your team invests in orchestration and guardrails.
Noma embeds generation, translation, and assistant flows so structured output and locale drafts are first-class—AI Generation and Translation, AI Assistant.
The decision is often build vs buy for AI glue, not whether AI is “possible.”
90-minute evaluation script
- Model one article-like entity in both (title, slug, body, media, relation to author/category).
- Create draft and published rows; confirm how preview and delivery differ.
- Add two locales (or your Directus equivalent) and fetch list + detail the way your Next.js or mobile client will.
- Run one AI or translation task (custom pipeline on Directus vs built-in on Noma).
- Measure time from schema change to working frontend fetch.
When Directus is often the better fit
- You need GraphQL or SQL-level reporting alongside content.
- The same database serves non-CMS workloads and must stay normalized your way.
- You have platform engineers who will own Flows, migrations, and performance.
When Noma is often the better fit
- You want editorial-first modeling with validation and hiddenInAPI-style field controls—see the schema checklist.
- You want AI-native drafts and translation without building the whole pipeline first.
- You want documented REST semantics for
locale,state, and translation resolution.
Summary
Directus is a strong choice when the database is the source of truth and the CMS is a layer on top. Noma is a strong choice when structured content operations—including AI and locales—should be productized end-to-end. Pick with a spike, not a checklist.
See: