Decoupled Drupal vs Next.js-Native CMSs: Which Should You Pick?

If you’re building a Next.js site that needs a CMS, you have a real decision to make: decoupled Drupal or a Next.js-native CMS like Sanity, Payload, or Contentful? Both work. Both ship production sites. And both are wrong for certain use cases.

This guide is an opinionated comparison. We build decoupled Drupal for a living, but we’ve also shipped Sanity, Payload, and Contentful projects. We’ll try to tell you honestly when Drupal wins, when a Next.js-native CMS wins, and what the tradeoffs actually are.

For background on each, see What is Decoupled Drupal? and Headless CMS Examples.

The basic shape of the decision

Decoupled Drupal = you run Drupal as a headless CMS backend, and build a Next.js frontend that consumes its JSON:API. You get Drupal’s editorial depth and a modern frontend.

Next.js-native CMS = you use a CMS built specifically for the Next.js world (Sanity, Payload, Contentful, Hygraph). These assume you’re building a React/Next.js frontend and optimize the editor experience accordingly.

Both architectures look the same from a visitor’s perspective — they serve a Next.js-rendered site. The differences are in the editor experience, the content modeling, the ecosystem, and the cost.

Where decoupled Drupal wins

1. Complex content models

Drupal’s content modeling has 20 years of refinement. Taxonomy, entity references, revisions, workflows, moderation states, multilingual, Paragraphs, Layout Builder — these are all first-class features that have been battle-tested on enormous sites.

If your content needs to express “articles in multiple languages, written by authors with multiple roles, reviewed by editors via a 3-step approval workflow, organized by a taxonomy tree that’s 4 levels deep, with structured blocks that editors can drag and drop” — Drupal handles that out of the box. A Next.js-native CMS can get there, but you’re building it yourself.

Drupal wins when: your content is genuinely complex, not just “a blog with tags.”

2. Editorial team size and roles

Drupal’s permissions system has 19+ permission types out of the box. You can build arbitrary roles: content editor, senior editor, legal reviewer, translator, etc. Each role sees only what they need to see.

In contrast, SaaS headless CMSs like Contentful charge per seat, and their permission models are simpler. For a team of 3-5 editors, this doesn’t matter. For a team of 50 editors across multiple departments with different approval hierarchies, Drupal’s permission flexibility is significantly better.

Drupal wins when: you have a large editorial team or complex approval workflows.

3. Workflows and moderation

Drupal’s Content Moderation + Workflows modules let you define state machines for content: draft → review → legal-approved → published, with different users having different transition rights. Revision history is full-featured, not an upgrade tier.

Most Next.js-native CMSs have basic draft/published states but less sophisticated workflow logic. Sanity has good real-time collaboration but no native moderation states. Payload has revisions but simpler workflow config.

Drupal wins when: you need real workflow states beyond “draft” and “published.”

4. Open-source, self-hosted ownership

Drupal is open-source and self-hosted by default. Your content lives in your database, on your infrastructure. Nobody can raise your pricing; nobody can change the product out from under you.

Contentful and Sanity can and do change their pricing and features. Payload is open-source self-hosted, so it shares this advantage. But Drupal has a much larger ecosystem of contrib modules, hosting providers, and experienced developers.

Drupal wins when: long-term vendor independence matters for compliance, cost, or strategic reasons.

5. Existing Drupal investment

If you’re already running Drupal, migrating to Next.js-native CMS means throwing away content modeling, custom modules, editorial workflows, and institutional knowledge. Decoupling preserves all of that.

Drupal wins when: you already have a Drupal site. This is the single most common reason for picking decoupled Drupal in the first place.

Where Next.js-native CMSs win

1. Developer experience

Sanity Studio, Payload, and Contentful all have cleaner DX for React-native teams. Schema is defined in TypeScript. Types propagate automatically from schema to frontend. The editor UI is often nicer to look at.

Drupal’s DX is not terrible, but it’s a Drupal DX — YAML config files, info hooks, Twig templates. If your team doesn’t already know Drupal, the learning curve is real.

Next.js-native wins when: your team is React/TypeScript-native and doesn’t want to learn Drupal.

2. Greenfield speed

Starting from zero, you can spin up Payload or Sanity and have a content model + editor UI + API in a day. Drupal takes longer: install, configure, enable modules, set up JSON:API, configure permissions, etc. For a small project where you don’t need Drupal’s editorial depth, this overhead is wasted.

Next.js-native wins when: you’re starting a new project and don’t already have CMS expertise.

3. Real-time collaboration

Sanity is the best-in-class here. Multiple editors can edit the same content simultaneously with real-time cursors and conflict resolution. Drupal doesn’t do this natively — two editors on the same node will get a “node is locked” warning.

Sanity wins when: real-time multi-editor workflows matter.

4. Visual editor

Storyblok and (to a lesser extent) Sanity offer visual editing where the editor sees a live preview of the frontend. Drupal’s preview is tunnel-based, not live.

Storyblok wins when: WYSIWYG visual editing is a must-have and you don’t have the engineering capacity to build it custom.

5. Small team, small site

For a marketing site with 3 page types, one editor, and a Next.js team of 2 people, decoupled Drupal is overkill. Payload, Sanity, or even a Markdown content collection in Astro will get you shipped faster with less maintenance burden.

Next.js-native wins when: the project scope doesn’t justify Drupal’s depth.

The decision tree

Here’s how we actually help clients pick:

Do you already have a Drupal site? → Decouple it. Don’t throw away a working CMS.
Is your content model complex (multilingual, heavy workflows, many editor roles)? → Decoupled Drupal.
Is your team React-native and has no Drupal experience? → Next.js-native CMS. Probably Payload or Sanity.
Is the project small (marketing site, blog, product docs)? → Next.js-native CMS. Overkill to run Drupal.
Do you need real-time collaborative editing? → Sanity.
Do you need visual WYSIWYG editing? → Storyblok or a traditional CMS.
Do you need long-term vendor independence and open-source self-hosting? → Decoupled Drupal or Payload.

Most of our clients end up on decoupled Drupal because they already have Drupal, have large editorial teams, or need complex workflows. If none of those apply to you, we’ll tell you honestly that a Next.js-native CMS is probably a better fit — and point you at Payload or Sanity.

Cost comparison