Engineering

When the content model outgrows the CMS

A content model outgrows a builder's CMS quietly. Webflow allows ten reference fields per collection on non-Enterprise site plans and twenty on Enterprise, per its own help documentation. Nobody notices that in month one. You notice in year two, when one page type has to pull in services, locations, industries, team members, certifications and related case studies, and the eleventh join is the one the interface will not let you add.

Where the joins run out

Webflow publishes the numbers, which is more than most platforms do. Ten reference fields per collection outside Enterprise, twenty on it. Collection lists nest three levels deep, ten nested lists per page, and a nested list renders at most 100 items per parent item. A page can carry 40 collection lists, and any single list shows 100 items before you have to paginate. Those are the walls of the room.

Contentful draws its lines in different places: 50 fields per content type, 1,000 entry links across all the fields of one entry, and references resolved ten levels deep. Neither vendor picked these to be difficult. They run shared infrastructure, and a query that fans out across six joins for one visitor costs them the same whether you meant it or not. Given that constraint, capping the model is the honest engineering answer.

What bites is the timing. You meet the ceiling after the model is committed, after the editors have learned it and 4,000 items live inside it. The workaround is usually to flatten: duplicate a field, keep a manual text list of slugs, or pre-render the related content into rich text so it stops being a relation at all. Every one of those decisions is reasonable on the day. Two years of them and the model only exists in the head of whoever made them.

The relation with nowhere to put its own data

A multi-reference field records that two items are related and stops there. Say a clinic references its doctors. Where do you record that one of them works Tuesdays, in room three, at a different rate, starting in March? The relationship has attributes and the field has no room for any of them. So the rate goes in a text field on the doctor, or in a separate collection keyed by a naming convention, and the model quietly starts lying about itself.

In PostgreSQL the same thing is a join table that holds its own columns, a foreign key in each direction, and a delete rule you choose on purpose. You also get to say that an appointment row must have a patient, and the database refuses the write if it does not. A reference field left empty in a CMS renders empty on the page, and you find out on a Friday when a customer tells you.

This is not a field-count problem. Airtable gives you 500 fields per table and 1,000 tables per base, far more than any sane model needs. The ceiling is shape. Once your content has relationships that carry their own data, a schema stops being overhead and starts being the cheapest way to keep the thing honest.

When staying put is the right call

Stay World Class hit this and moved. Webflow and Xano came out, Next.js, NestJS and Supabase went in, and the content came across through a four-stage ETL that mapped every legacy ID to a PostgreSQL UUID so nothing lost its history. Lighthouse went from 55.91 to 91 out of 100 and LCP got 77% faster. The ETL was the expensive part, and it was expensive for the reason above: relations that had lived in naming conventions had to be reconstructed before they could be written as foreign keys.

If your content is posts with one author and one category, stay where you are. If editors publish every day, nobody has asked for a filter the CMS cannot build, and no relationship in your model needs to carry data of its own, a migration costs you weeks and buys you a schema diagram. That is a bad trade and you should not make it.

The signal to watch for is smaller than a limit error. It is the day someone stores relationship data in a text field because there was nowhere else, or the day you build the same lookup by hand for the second time. That is the model telling you it has outgrown its container. You can wait after that, and plenty of teams reasonably do. It is worth knowing which problem you are living with.

Sources

Is your platform outgrowing its stack?

Book a call and we'll walk through how we'd approach your platform, with an estimate grounded in a working prototype.