Contentful logo

Contentful Community

More Content Types

We have been testing out your platform for a while now and it’s really great. One gripe we have though is the limit on the number of content types that you can create. You have to spend $489/mth to get more than 24 content types which is very expensive for a small startup that wants to create a rich content model. The only option is to split the content into multiple spaces which isn’t ideal.

There should be more content types available on the Small tier so that you can incrementally move up the tiers rather than having to make big price jumps to get more content types.

1 Like

Hi @R101,

I don’t pretend to know anything about your project, but I’ll say this: Every, and I do mean every single time I’ve seen people run out of content types, it’s the result of bad content modeling. Instead of going for more content types, I would recommend re-evaluating and re-designing your content types.

I’ve worked on plenty of projects with complex data models and hundreds of tables in a relational database. Contentful would be capable of supporting these models but completely impractical from a cost perspective.

We are currently considering using Contentful on a number of projects with some fairly complex data models that will require numerous content types to support the data relationships. You then add in extra content types to provide richer layout options for rich text fields and you quickly burn through the content types.

These tight restrictions on content types mean having to consider annoying workarounds like splitting the model across multiple spaces.

I realise that Contentful price things specifically to get you to move up to higher priced tiers but there are huge jumps in price just to get additional content types, e.g. an extra $450/mth to get more than 24 content types versus just $39 if you split the model into another micro space instead. I know which option we would be going with, but it’s an annoying limitation.

I would prefer to see a more flexible pricing model with a mix and match approach where you can pay extra to obtain more content types/records/roles/locales/sandbox environments, etc.

I want to second what @teemu.tammela1said above. Same as him, I’m not pretending to know anything about your project, but we have a semi complex content model, that we were able to implement using just 4 content types. You might want to have a 2nd look at your content model and see if you can consolidate some. Just a thought, again, you may actually need more than 24, but it seems like a lot for just one project.

I’m not sure we are talking about the same thing here. Sure, if you are creating a basic blog or marketing site, then you can survive with a handful of content types along the lines of Wordpress authoring as the data capture requirements are fairly simplistic and it’s mainly text content that you are capturing in the model.

But, if you want to create a more sophisticated application with complex data capture, multiple hierarchies & many relationships then you need a lot more content types just to store that data. For example, we can’t take a relational database with 200 tables and flatten that into 4 content types. The model is just way more complex than that.

We also need to be able to offer editorial staff more sophisticated ways to format articles beyond the basic formatting options in the standard rich text field, e.g. responsive grids, tables, review cards, callout boxes, floated images, etc. These need to be embeddable at any place within the rich text field.

So, we create additional content types to capture just the data for these embedded pieces of content and then use custom content renderers to render the rich text content as HTML in the web application with the appropriate layout & styling.

Are you able to share a link to the site you are referring to that is authored with just 4 content types?

So unfortunately, it’s behind the paywall, so I can’t. But again, I was not trying to assume your project was simple. Just a tip to maybe revisit your complex relationships and double check to see if you can “simplify” it a bit. Perhaps, in your case, it’s just not possible.

Are you able to share your content model?

As it happens, I’m able to offer a reference project that uses just 4 content types. Granted, I’m not claiming it’s a very complex project, but a reference point nevertheless. The source code is publicly available, in case you wish to dig under the bonnet.


For another reference, I have designed the content models for terve.fi, apu.fi and meillakotona.fi (they all have the same content models and platform). The aforementioned sites are one of the most popular lifestyle sites in Finland. They are fairly complicated and content-heavy (entries counted in the hundreds of thousands). Those particular websites have about 15 content types, IIRC.

Thanks for providing the links. The sites look great by the way!

Looking at the source code for AuralCandy.net and from what I can tell from the other links that you sent, these sites all have very simplistic content models. There’s just not a lot of data to capture and they seem to be marketing sites rather than applications with rich interactivity.

I am talking about far more complex sites with a variety of product categories, complex price comparison and a rich & interactive user interface.

Anyway, it is what it is, so I think we might end up with either splitting our model into separate spaces or carving out some of the data into a standard relational database and using Contentful just for managing the editorial content, which is where it really excels anyway.

We’re also looking at other offerings such as Directus, which is really powerful, and as it’s open source so you can self-host with no limits on content types or records. I do prefer some of the features of Contentful though, so still undecided.

I agree, Contentful excels especially in editorial content. Building application-like, data-heavy functionality by using Contentful as the singular data storage may indeed prove impractical.

At the end of the day the biggest question is 1) what kind of editor interface do you need for your every particular piece data and 2) how often are they subjected to change and by whom.

On a related note, it might also be worth looking into JSON field type in conjunction with UI extensions. In the projects that I worked in in the past we found that to be a very effective way of both keeping the number of content types down and providing a better user experience than building everything with native reference fields.

Yeah, the JSON field type is interesting and we have been experimenting with that as it seems to be the only way to support tables within a rich text field. There are some useful extensions for that already and I can certainly see how powerful that could be for supporting any type of UI and content structure.

But…that doesn’t really help when you want to embed other content into a rich text field as you still need to create a content type to wrap the JSON field that you then embed into the rich text field. I guess you could create a multi-purpose JSON field with different UIs that you could select in your custom extension with different JSON data structures, but that sounds like a lot of effort just to workaround the content type limits.

The native support for embedding content types is so flexible and useful that it’s annoying to not have the freedom to use that more extensively.