Skip to main content
Mediacurrent logo
Hero Background Image

Blog Post

Comparing Contentful and Drupal on Common Ground

by Dan Polant
January 22, 2021

Drupal vs Contentful by Mediacurrent

Why is Contentful CMS gaining popularity in the headless CMS space?

At Mediacurrent, our roots in the Drupal ecosystem go deep. We are experts at deploying Drupal sites, building with Drupal, and working around its shortcomings. For these reasons, it is important that we understand the situation when a new CMS starts to trend, and especially that we give it a fair assessment. We need answers to questions like: What can Contentful offer our clients? What are the risks in adoption?

The Contentful Gambit

Let’s start by talking about what Contentful is trying to do as it emerges as a competitor to Drupal. Like many headless CMS vendors, Contentful wants to be the CMS that modern, growing companies choose - and the modern, growing companies of today are finding success with microservices. Thus Contentful prioritizes that their product is slim and fast, and fits in well alongside other microservices. I would summarize Contentful’s central gambit like this:

  • Big enterprises are adopting microservice architecture, so they will like Contentful more than monolithic CMSs.
  • Contentful’s SLA will entice big enterprises.
  • Small/medium organizations will choose Contentful because it is easy to spin up and has superior UX.
  • Contentful’s current, and growing feature set is enough for both of these segments with minimal sacrifices.

How are Drupal and Contentful Different?

If you are reading this as a technical decision maker, you may already know that when you make the business case for a tool, it must be a good fit for not only your current needs but also for your needs some number of years in the future. You want that number to be as high as possible, but also you do not want to pay too high a cost when, at some point, you need to replace the tool with something else. With this context in mind, I would like to present readers with the most meaningful dimensions for comparing Drupal and Contentful:

  • As a CMS
    • Editor user experience
    • Editor Roles and Workflows
    • Image asset handling
    • Content modeling power
  • As a platform
    • Scalable devops workflows
    • Stability and security
    • Stack profile
    • Cost model

Comparing Drupal and Contentful involves more than contrasting their respective abilities as applications. Drupal is an application, whereas Contentful is a platform - or “content infrastructure” as they often call it. This distinction muddies the Drupal-Contentful comparison when critics focus solely on what each can do as an application, or “as a CMS.”

Nevertheless “what can it do?” is an important dimension of comparison. The rest of this article will attempt to weigh the answers to that question fairly against other concerns that come into play when one considers that an organization’s CMS could in fact be a platform, rather than an application.

Editor user experience

I would like to highlight a few points that impact the user experience of content editors, meaning those who make updates to content for an organization.

Structured content UX

In the old days, we often used wysiwyg editors to store large chunks of content that we needed to show up on a given page. There were lots of problems with this, chiefly that it made it very hard to enforce consistency across different pages. Most modern content management approaches have now moved on to “structured content,” which works more like this:

  1. Architects and stakeholders define:
    1. What pieces of content a site has
    2. What attributes the content pieces have
    3. The relationships between those pieces.
  2. Editors populate and relate the pieces of content.

In the Drupal world, first came the Paragraphs module, and then along came Layout Builder to provide structured content solutions. Mediacurrent has had long-term success with both of these modules. Check out our presentation comparing Paragraphs vs Layout Builder in Drupal.

How does Contentful stack up to the Drupal structured content solutions? See the matrix below:

SolutionChild component editing UXSupports HeadlessHas “section” concept
Drupal - ParagraphsPoor - no modal screens, easy to lose place when editing child componentsYesNo
Drupal - Layout BuilderGood - page components (blocks) appear in modal windows. Lacks some polish though.No, although there is an initiative.Yes - great because you can drag page components easily between sections of the page
ContentfulExcellent - Contentful’s editor was designed specifically to support nested content, even a few layers deep.YesNo

Among all solutions, I would say Layout Builder and Contentful are close in terms of UX for structured content - especially given Layout Builder’s incorporation of the “section” structure.

Layout Builder Structured Content UI with Sections

Drupal layout builder showing the ability to add a new custom block


However Layout Builder doesn’t support decoupled sites at the moment, so that discounts it for the moment in our comparison of headless CMS solutions.

Pitted against Drupal Paragraphs then, Contentful is a clear winner in terms of UX. It is crucial for Drupal to add decoupled support for Layout Builder for it to remain competitive.


Contentful’s Slide-in Editor for Nested Content

Contentful’s Slide-in Editor for Nested Content

Modal interactions are important when nested content is involved. Contentful designed their UI to support deeply nested pieces of content. Without a modal overlay, users can easily get lost when a new panel opens up. This is a big problem for the Paragraphs module.

Paragraph Structured Content - Flat Model

Paragraph Structured Content Flat Model


Views for CMS editors

In Drupal, the Views module helps admins and developers assemble useful content lists for other users. I have a feeling that we may miss this functionality in Contentful, where saved lists are much less flexible. As a long time Drupal developer and architect, we don’t make a ton of Views for editors on every site, but it does provide significant value at times.

Drupal Views - Highly customizable lists for editors

Drupal Views - Highly customizable lists for editors

Contentful’s list customization is much more limited.

Contentful Shared Views - Basic list building
Basic list building

Admin UI translation

Contentful doesn’t support translation of the content editing UI, while Drupal does. This means Contentful editors do not get the opportunity to view the UI in their native language if it is not English.

Editor roles and workflows

The CMS user role capacities of Drupal and Contentful are well documented, with Contentful being less flexible than Drupal in this respect. This goes along with Contentful’s main gambit: they feel that the benefits of being a CMS platform outweigh the cost of lacking powerful IAM logic within the CMS.

To explore further, let’s contrast some of the ways in which Contentful and Drupal approach access management.

The user entity (Drupal)

One neat thing that you can do with Drupal is putting fields on the user entity. While decoupled sites typically use a third-party identity framework for “visitor” users, it can still be useful to be able to add attributes to your CMS users. Custom access control logic often relies on this capability.

manage fields

The Space entity (Contentful)

Contentful lacks any ability to add custom attributes to CMS users, besides basic things like name and email. However, it does add a useful structure into the mix that can help accomplish content governance: The Space.

Contentful Space Concept

Contentful space concept

Consider the following user story: An organization's department needs to restrict access to their space to just their own personnel.

Some users from the organization must be able to update content in all departments.

With Contentful spaces, you could:

  1. Create a space for each department
  2. Sync a common content model to each space using the Content Management API.
  3. Create users with roles at the organization level for staff who need overarching access.

While compelling, this setup is not as powerful as being able to add and make use of user entity attributes, and has some clear drawbacks - chiefly, that users in different spaces are completely isolated and wouldn’t be able to use any content from the main space.

This sounds bad, but to organizations adopting a decoupled approach, it might not be. Consider the following scenario:

  • Organization uses spaces for each department.
  • Developers sync and mutate the content model for all spaces using the CLI as needed
  • Media is stored in a DAM (e.g. Cloudinary), so users in any space can access by using the Contentful Cloudinary app.
  • E-commerce data, where needed, is brought into Contentful admin using a custom field, or a supported Contentful app if it is available.
  • Frontend app (e.g. gatsby) gets microcopy and shared content from a central space.

Here is a diagram that shows what this setup could look like:

decoupled Contentful

Contentful believes that this kind of setup can benefit a wide range of organizations, including enterprises. It is very different from a monolithic CMS (even a monolith headless CMS) and will seem appealing if you buy into the general premise of decoupled applications. The risk of course is that you run into an immovable object - a hard content governance requirement for your organization that Contentful simply can’t support. Contentful’s hope is that Contentful itself is slim enough that organizations don’t require very much access control within it. Organizations may then rely on the nature of microservices to keep editors out of things like e-commerce, for example.

My experience tells me that we should not brush aside the need for nuanced content governance amongst CMS users. Contentful is betting high that the Space entity can solve for this, and this solution will likely fall short for some organizations until Contentful decides to implement a more robust IAM system. But will it fall short enough that enterprises pass up a CMS platform where (assuming you pony up) an SLA guarantees availability? That is much harder to tell.

Image handling

Both Drupal and Contentful have fairly sophisticated ways of not just storing images but making them available at a variety of resolutions and aspect ratios.

Drupal - consumer image styles

Lullabot wrote this excellent module and they explain it best in this blog post. In summary, Consumer Image Styles does the following:

  • Limits which image variants may be delivered to a given frontend consumer (e.g. a Gatsby site), so that an attacker cannot fill up the disk with the whole matrix of possible image variants.
  • Adds supported image variants to JSONAPI responses

Contentful - Image API

Contentful has its own Images API that provides image derivatives to consumers. Being a platform, Contentful can prevent image variant stampedes at the infrastructure level.

Screenshot of Contentful Image API, cropping example

Contentful image API

I give an edge to Contentful in the realm of image handling because it is native and security is done behind the scenes. You don’t have to worry about “providing presentation dependencies” for your frontend.

Also, Contentful provides a scalable image storage solution (AWS S3), and natively Drupal does not. There is an S3 storage contrib module for Drupal, but it does not integrate seamlessly with Consumer Image Styles.

Content model power

This dimension is quite important for a content management solution because it concerns that solution’s ability to define how content is segmented and related, and what metadata it may possess.

Contentful: entry entity for all segments of content

Contentful proposes that a single, fieldable entity type is sufficient for the content modeling needs of organizations of any size. They call this the “entry.” Entries can represent a whole page, or they can represent segments of content related to other entries via reference fields.

There is also an entity type that is similar to Media in Drupal - the Asset. Assets are slightly less powerful though because they are not fieldable. Contentful recommends that you wrap Assets in an “Asset wrapper” entry type if you need to add metadata beyond title, alt value, and description. This is a bit unwieldy.

Drupal: nodes, terms, blocks, and more

Drupal’s content modeling capabilities outclass those of Contentful. Let’s take a closer look at that margin:

Fieldable Media EntityThis gives Drupal a small advantage over Contentful, since it means architects do not need to model a “media wrapper” entity type if they want media assets to have extra fields.
HierarchiesUsing reference fields, it is possible to establish content hierarchies in Contentful, but Contentful lacks a tool in any way similar to Drupal’s taxonomy hierarchy listing. This is more of an interface level advantage rather than modeling specifically, but it is significant enough to note that Contentful lacks a drag-and-drop term tree interface.
Full control over field cardinality

 Only reference and text fields are allowed to be multivalue in Contentful, whereas in Drupal a site builder may select cardinality for any field separate of type.


The Drupal taxonomy hierarchy manager


The Drupal taxonomy hierarchy manager

CMS comparison conclusions

By now, you should be noticing a trend: as a CMS, Drupal has more flexibility and power than Contentful. This is not the end of the story, however - because Contentful is actually a platform, not just a CMS. This came into play a little bit as we discussed Contentful’s Image API. 

I hope the CMS comparison has given readers a takeaway about the margin of Drupal’s superiority in content modeling, perhaps to be weighed against the margin of Contentful’s superiority in terms of user experience. In the next big section of this article, we’ll discuss what it means to compare the platform side of contentful with a fair equivalent in the Drupal universe.

Comparing Drupal and Contentful as Platforms

Let’s start by asking: what does it mean to compare Contentful to Drupal “as a platform?” We should also get our terms straight: in this context, “platform” means the whole technology stack that supports a particular service, as well as the service itself. Contentful is a platform - you do not have to install it anywhere, and once you obtain a license as an organization, it is available for you to use in order to supply content to your business.

If Drupal is your CMS, then what makes up the rest of your CMS platform? Chiefly, it is your CMS hosting solution. Have you installed Drupal on an AWS server in a DIY fashion? Or did you use a managed host like Pantheon or Acquia? Whatever the case may be, your CMS platform encompasses the Drupal application itself, plus the capacities that your Drupal hosting solution provides in order to make the content in Drupal available where it is needed.

Application versus Platform model for CMS

Figure 1: Application versus Platform model for CMS

In the next few sections, we will explore a few dimensions of this as-a-platform comparison.

Stability and security

Much of this article has shown Contentful at a disadvantage in terms of capability and flexibility as a CMS - and you may be wondering, then, why is there buzz around Contentful? The answer begins with this: that Contentful offers some very enticing promises in terms of guaranteeing availability and security for your content.

Contentful - Autoscaling, Delegated security model, SLAs

To keep your content available for the highest percentage of the time, Contentful will autoscale its API performance as needed. On the security front, data is encrypted at rest and in transit, and Contentful takes sole responsibility for keeping itself secure, throughout the whole technology stack.

These items make it possible for Contentful to provide an SLA that guarantees availability of an organization’s CMS platform (for a price). Enterprises are likely to find this enticing - and this is something that is unavailable to organizations running the Drupal stack. Managed Drupal hosts may sell a guarantee of server uptime with an SLA, but not availability of the Drupal application itself.

Drupal - Open source security, managed hosting

The Drupal security team is dedicated to keeping the Drupal codebase free of vulnerabilities and communicating security updates to the public in the best way possible. Still, it falls to agencies and organizations to apply these updates quickly to individual sites. This responsibility model is less palatable than being able to delegate all CMS-related security to a third party (though hackers could still compromise a platform like Contentful).

Moving to discuss availability, Drupal is much harder to autoscale than a slimmer service like Contentful. Some Drupal hosting solutions have a containerized architecture that supports autoscaling, but it doesn’t flex as well as something like Contentful. Gatsby static site builds, for instance, have a nasty habit of causing 502 errors on Drupal environments: the type of scaling needed to keep the Drupal stack available under bombardment has a much harder time keeping up. While some hosts have made great strides in containerizing Drupal hosting, other solutions require you to pre-plan for traffic spikes by paying for expensive hardware year-round.

Cost Model

We have already talked a bit about cost as we discussed how both Drupal stacks and Contentful provide stability and security. Thus, when comparing costs of the two CMS solutions, use the following table as a guideline:

CMS PlatformCost Factor
ContentfulContentful subscription fee
Drupal stackDrupal hosting fee


Price points are a game of cat and mouse between competing platforms, so it is hard to record and compare specifics in a way that will be meaningful for much of the future. But for the moment, we can provide some insights about the respective price models involved with adopting Contentful versus the Drupal stack.

Contentful - Competitive medium tier, slippery slope

Contentful’s medium-tier seems like a lot for a CMS - but remember - that cost replaces what you might otherwise pay to a managed Drupal host. These are expensive too, often much larger than Contentful’s medium tier.

But here’s the catch. As of today, Contentful slyly funnels you towards enterprise-level “call us” pricing by limiting the number of entry types allowed on the medium tier to 48. That 48 entry types includes things that in the Drupal world we would classify as taxonomy terms, paragraph/block components, and nodes. It will get used quickly on any project. Of all the concerns about Contentful, this one is most worrisome, and in my opinion, represents a significant hurdle to adoption because it means your fees can vary wildly based on a hard-to-predict attribute of your content model.

Drupal stack - Hosting fees, free CMS app

Drupal hosting fees have some potential for unpredictability, as we discussed in the stability and security section. For most organizations though, they remain a fairly stable fixture. At the enterprise level, the hosting fees of managed Drupal are likely similar to a Contentful enterprise license, but this may be unproductive to speculate about since each situation is different.

Scalable devops workflows

Admittedly, this section is a bit of a grab-bag. Think of it as factors that impact coordinating development, deployment, and testing across a suite of different environments.

Code deployments

You would only ever have to deploy new code to a Contentful environment if you were working on a backend UI customization or app. For Drupal, on the other hand, best practice deployment workflow for any kind of code deployment (including config) involves complex CI architecture, chiefly because you should avoid running Composer processes in a production environment.

Tracking and propagating configuration changes

With the Features module, Drupal 6 pioneered the concept of configuration-as-code in the CMS application market. Think of this as the ability to stamp your CMS configuration into code so that a) you can track revisions to it via version control software and b) mutations can be applied uniformly to any environment. Fast forward to Drupal 8 and this type of configuration management is in core and extremely reliable.

Drupal content model in YAML code

Drupal content model in YAML code

Contentful also embraces this philosophy of capturing configuration in code. They offer the Content Management API as a solution. This has both advantages and disadvantages in respect to Drupal’s Configuration Management API.

Contentful Content Management API

Pros: It is a REST API

Cons: All mutations must be hand-coded (similar to hook_update if you are familiar with Drupal).

DrupalConfiguration Management API

Pros: There are simple commands to “stamp” the full config-state of an environment to code.

Cons: Not a rest API, differences in configuration between environments are tricky to handle.

Below is some example code for Contentful’s Content Management API, for updating the name of a content type.

const contentful = require('contentful-management')

const client = contentful.createClient({
  accessToken: '<content_management_api_key>'

  .then((space) => space.getContentType('<contentType_id>'))
  .then((contentType) => { = 'New name'
   return contentType.update()
  .then(contentType => console.log(contentType))

I give the edge to Drupal here. Let’s note: some of today’s headless CMSs, for instance, Sanity and Netlify CMS, do not even provide a UI for content modeling. Contentful provides a UI but forces you to pile up layer after layer of Content Management API code to track future updates. I think this is a weakness. Drupal on the other hand gives you the best of both worlds: mature “content model as code” tooling, plus a user interface to make the changes so that developers don’t have to memorize a detailed schema framework in order to accomplish simple content modeling tasks.

Multi-environment capacities

Contentful, as well as the Drupal stack if you pick the right hosting provider, support creating multiple environments for whatever purpose you need. Here is a breakdown:

ContentfulEnvironment concept

Pros: This capacity is bundled with Contentful itself, and the Environment Aliases concept adds another useful tool.

Cons: No way to set up local instance of Contentful.


Depending on host, either:

  • Turnkey solution
  • May ask host to provision new managed environment
  • You can provision a new Drupal instance on your own and set up tooling.



Pros: Some Drupal hosts have excellent multi-environment tooling available

Cons: Highly dependent on which host you choose.

One note about local environments - if your project is headless, there isn’t a great reason to use a local instance, provided you can provision a new environment easily for whatever task you are working on. The only place I can see this being cumbersome is if you are working on a backend customization to the Contentful admin UI using their plugin system.

I have to give the upper hand to Contentful in the multi-environment category. Too much depends on choosing the right Drupal host, and all of them have quirks that may make the decision difficult. For instance, the Drupal host with the best multidev support also locks you into a release pattern that doesn’t quite jive with the popular git-flow concept.

Contentful also has a concept called “Environment Aliases” that lets you switch the production environment for a release instead of deploying changes to a set production environment. 

Contentful Environment Aliases

Contentful Environment Aliases


Multi-site capacities

By multi-site, we mean the ability to create and maintain a family of CMS instance-siblings that share common elements of a content model, but remain administratively separate. We are not talking about the frontend here because we are only concerned with headless scenarios.

If you are running Contentful, the Space entity would provide a solution, though you would have to write a middleware layer that propagated content model changes to each space. You would need to come up with your own system for how each site handled its frontend expression - this could be a family of Gatsby repos integrated with Netlify, for example.

In the Drupal world, you could be using Drupal native multisite capacity, or you could procure Acquia Site Factory. You would sync config using Drupal’s config management API.

Here is a breakdown:

ContentfulSpace entity

Pros: easy to provision, comes with Contentful license.

Cons: Middleware needed to sync content model across spaces.

  •  Drupal multisite
  •  Acquia Site Factory
  •  Aegir

Pros: You can use Config Management API to sync configuration across sites.

Cons: Native multisite and Aegir are tricky to implement and brittle. Acquia Site Factory is expensive.


Platform stack profile

Technical decision-makers at organizations, especially those we might refer to as enterprises, often have a particular vision based on current technology trends. And today, it is impossible to talk about any of this without discussing microservices. I want to stay away from the debate over whether microservices are good or bad, or overhyped: regardless, they are a big part of the application architecture landscape today. When choosing a CMS, a lot of CTO types will be looking for something that “feels” like a microservice and fits in within their current ecosystem of microservices.

Depending on how you define microservice, Contentful is one or is pretty close. Could a headless Drupal CMS be a microservice? I would say no - it is a service but it is not “micro.” Drupal does not really follow the philosophy of “do one thing and do it well” (see Even though it can fill the same role as Contentful, Drupal’s stack profile is that of a swiss-army-knife/monolith, and not a microservice.

What counts in Drupal’s favor in terms of its stack profile? Undoubtedly, the answer is that it is open source, through and through. This is meaningful to many organizations today, especially in government and higher education - and it is down to more than sentimentality. Open source principles make up the foundation of critical web infrastructure (chiefly Unix itself) - because they provide a long-term model for extensibility and evolution. And back to what some might call “sentimentality” - having a software model that fits with the ethical mission of your organization is certainly not a factor to dismiss, and often lies at the heart of technical decision making.

So which way is better, microservice or open source stack? Here’s how you might decide: do you value “doing one thing well” more than the value of open source development practices? If so, Contentful makes sense. If you feel the opposite way, go with Drupal (or another open source CMS).


Comparing Drupal and Contentful is so difficult because despite the fact that although they are both CMS solutions, they differ in fundamental ways. Since this article has covered a lot of ground, I want to provide more of a condensed visual comparison in the tables below:

Comparison Matrix: As a CMS

Editor user experienceContentfulMostly down to the superb UX of Contentful for handling structured, nested content.
Editor roles and workflowsDrupalDrupal lets you customize the CMS user model in order to support access logic.
Content modeling powerDrupalContentful is close but lacks a few useful capacities that may cause technical debt.
Image asset processingContentfulContentful handles image processing natively and more smoothly and has native integration with many DAMs.


Comparison Matrix: As a Platform

Stability and securityContentfulContentful guarantees this for you so you do not have to handle it on your own.
Scalable development workflowsDrupalA close one, but it is hard to beat the power of Drupal’s configuration management API. Caveat though if you are thinking of multisite.
Stack profileToss upDepends too much on your organization’s overall philosophy. Please read the section!
Cost modelDrupalUntil Contentful changes the 48 entry type limit for the non-enterprise tier, cost will be a big issue.


Decision Time

You will have to decide how to weigh the dimensions listed above. Is the thing you value most in a CMS editor user experience? Seriously consider Contentful in that case. Worried about cost? Beware of Contentful’s 48 entry-type limit while also considering how you might use the Space concept to divide content up amongst different spaces - and that this cost will replace any hosting costs you would have incurred by choosing the Drupal stack. Is your organization steeped in the open-source software model, or in that of microservices - and what are your pain points with your current model? 

If your organization is about to upgrade from Drupal 7 to Drupal 8, you are at a good point to consider Contentful as an option. Mediacurrent is a Contentful Partner, and we also have extensive experience in Drupal - we can help you weigh your options.


Meet team member, Dan Polant

Dan specializes in architecting and implementing large, complex projects. His approach: to provide confident technical leadership and clear, honest communication, because projects need both to succeed.

Related Insights

  • Headshot
  • Headshot
  • Headshot
  • Headshot