Draftbase vs Contentful: Content Modeling

Draftbase and Contentful are both headless CMS platforms. They model content differently in ways that matter once you build a real schema. Draftbase stores rich text as a plain MDX string. Contentful stores it as its own JSON node tree, and its free tier caps out at 100,000 API calls a month. Pick Draftbase if your frontend is React or Next.js and you want MDX components inside content. Pick Contentful if your team is already deep in its ecosystem and needs proven scale.

How do Draftbase and Contentful model content?

Both platforms use a schema-first approach to content modeling. You define a content type once, made of typed fields. Every entry against that type has to match it. That's where the similarity mostly ends.

Draftbase ships eight field types out of the box: text, richText, number, boolean, date, media, reference, and JSON. Each one carries its own checks: regex and length rules on text, range checks on numbers, a required flag on any field. Reference fields protect integrity directly. You can't delete an entry something else still points at.

Contentful's field types run wider. Short text, long text, rich text, number, date, location, media, boolean, JSON object. Plus two kinds of reference: single and array. Its validation set covers unique values, regex patterns, and number or length ranges. You configure it through the content model editor or the Management API. On paper, the two platforms cover similar ground.

Where the two diverge: schema location

The practical difference is where the schema lives day to day. Draftbase's schema is a template you edit in the same admin your team already uses to write entries. Contentful works the same way, a content type model in its web app, editable by anyone with the right role. Neither stores the schema as code by default. If schema changes need version control and review, both need a workaround. Use Contentful's Migration CLI, or Draftbase's management API. For the broader case on treating content types as data first, see schema-driven content modeling.

How is rich text stored, and why does it matter?

This is the field type that decides how painful a future move gets.

Contentful's richText field returns a JSON document. The root node has nodeType: "document". Every paragraph, heading, or embedded entry is its own typed node, each with nodeType, data, and a nested content array. It's expressive. A rich text field can embed a live reference to another entry inline, not just link to it. Turning that document into HTML or React needs @contentful/rich-text-react-renderer. You write your own renderNode map, per project, per framework.

Draftbase's richText field stores a plain MDX string instead. @mdx-js/mdx compiles it server-side, and @draftbase/renderer renders the result as a React Server Component. A paragraph, a GFM table, and a custom <PricingTable /> component all compile through the same path. The components prop is the only door a compiled MDX document has into your app's React tree. evaluate() runs without useDynamicImport, so an import statement inside CMS-authored content throws instead of executing. That's a real security boundary, not a marketing line.

Neither format is "more structured" than the other in a way that helps content survive a platform switch. Contentful's document tree is Contentful's own shape. Draftbase's MDX string is at least plain text. A grep can search it and a diff can show it line by line. The section below covers why that matters more than it sounds. See MDX vs Rich Text: Which Should a CMS Store? for a deeper breakdown of the two formats.

Does either platform keep revision history?

Yes, both do, with different depth.

Draftbase tracks full revision history on every entry, with rollback to any prior version. It also has draft, published, and archived states, plus scheduled publishing. Contentful tracks entry versions too. Its higher tiers add release-based publishing and workflow approvals on top. That's useful once a team grows past a handful of editors and needs a review step before anything goes live.

For a small to mid-size team, the two are close enough that revision history alone shouldn't decide the platform. It becomes a real difference in two cases. One: you need multi-step approval workflows, where Contentful's higher tiers pull ahead. Two: you need reference integrity that blocks a delete outright, which Draftbase enforces by default.

What does the delivery API look like?

Contentful serves published content over a Content Delivery API (REST) and a GraphQL Content API. Both are rate-limited to 55 requests per second per space. Cache hits don't count against that limit, so a well-cached frontend rarely feels it. Draftbase's delivery API is also REST and GraphQL, cached and rate-limited per org. It adds cursor pagination plus both keyword and semantic search out of the box.

The bigger gap is typing. Contentful doesn't generate TypeScript types from your content model on its own. Someone on the team writes and maintains them by hand, or wires up a codegen script. Draftbase ships a draftbase-sync CLI. It reads your templates and writes a <TemplateName>Fields interface per template, straight from the schema. A field rename shows up as a compile error in CI, not a runtime undefined three components deep.

How much does each one cost?

Plan tier	Draftbase	Contentful
Free	Hobby, $0	Free, $0 (10 users, 100k calls/mo)
Entry paid	Startup, $49/mo	Lite, ~$300/mo (billed annually)
Mid	Growth, $299/mo	N/A
Higher	Scale, $499/mo	Premium, custom (enterprise)
Top	Enterprise, custom	Premium enterprise, custom

Contentful's jump from free to Lite is steep. It's roughly $300/month at the entry paid tier. That's why teams often stay on the free plan well past the point they need more than 10 users or 2 roles. Draftbase's Startup tier sits at $49/mo instead. It's a smaller first step for a team that's outgrown free but isn't running enterprise content volume yet.

How hard is it to migrate between them?

Moving Contentful content into Draftbase, or back, means rebuilding content types and entries through each platform's management API. Draftbase's MCP server can drive that rebuild directly from an agent. It reads Contentful's exported content types and writes matching Draftbase templates and entries, no hand-built script per field.

The rich text field is where the real work piles up. Contentful's document-tree format has no shared open standard across CMS platforms. A script has to walk every node. It rewrites embedded entries, marks, and block types into whatever the target platform expects. A flat MDX string doesn't need that walker. It's already the format most React-based CMS platforms, including Draftbase, read and render directly. Our CMS migration guide covers the general steps for moving to a headless model.

When is Contentful still the right call?

Not every team that reads this comparison should switch. Contentful's roles and permissions run deeper than a two-tier system. Large teams get fine-grained content-type-level and field-level access rules, useful once 30 editors touch the same space. Its localization tooling is also more mature. Fallback locales, per-locale required fields, and per-locale validation all ship out of the box. It's built for a team publishing the same content in a dozen languages at once.

If your team already has that scale, or is about to, the switching cost outweighs anything this post covers. A migration script, a re-trained editorial team, and a re-wired CI pipeline cost real weeks. Weigh that against what you'd actually gain: MDX components, a lower price floor, a typed SDK. For a two-person team on Contentful's free tier building a marketing site, none of that pays for itself yet. The free tier's 10 users and 100,000 monthly API calls cover most small projects without hitting a wall.

The decision gets easier once a specific pain shows up. A field rename that breaks production without a compile-time warning. A rich-text renderer that needs rewriting for a second frontend. An invoice that just crossed the Lite tier's $300 floor. Any one of those is a concrete reason to run the comparison below for real, instead of on price alone.

The underused angle: rich text format decides the migration bill, not the seat price

Every Contentful-versus-something post leads with the price jump to Lite. That's real, but it's not the number that actually blocks a migration. Contentful's rich text field is Contentful's own JSON shape, no shared spec, no cross-CMS parser. A team with 40,000 words of rich text spread across 300 entries doesn't pay that cost in dollars. They pay it in a migration script instead. Someone writes it. They test it against every embedded entry type. They re-run it when it breaks on the one entry with three nested lists nobody remembered existed. Pricing changes are visible on day one. The rich text format cost only shows up the week you actually try to leave.

Which should you pick?

Pick Contentful if your team already runs on it. Or if you need enterprise-tier approval steps, or content volume Draftbase hasn't proven at yet. Pick Draftbase if you're building in React or Next.js. You want MDX components with typed props inside your content, not a vendor rich-text tree. And you'd rather start on a free Hobby plan than a $300/month floor. Start free on Hobby, no card required. See whether a plain MDX string cuts the rendering work a JSON document tree adds.