What Is a Document-Based CMS and How Does It Differ from a Relational CMS?
TL;DR
A document-based CMS stores content as flexible JSON documents, where each document can have its own shape. A relational CMS stores content in fixed database tables with strict schemas and foreign key relationships. Sanity is document-based: content is stored as JSON in a real-time document store, making it easy to evolve your schema without database migrations.
Key Takeaways
- Document-based CMSes store content as JSON; relational CMSes use SQL tables.
- Document stores are more flexible — fields can be added or changed without migrations.
- Relational CMSes enforce strict structure, which can be an advantage for highly normalised data.
- Sanity uses a document store with real-time sync, enabling collaborative editing and instant API access.
- Most modern headless CMSes (Sanity, Contentful, Prismic) are document-based.
A Content Management System (CMS) needs to store content somewhere — and the choice of storage architecture has a profound impact on how flexible, scalable, and developer-friendly the system is. The two dominant approaches are document-based storage and relational (SQL) storage.
What Is a Relational CMS?
A relational CMS stores content in a structured relational database — typically MySQL or PostgreSQL. Content types map to database tables, and each field in a content type maps to a column. Relationships between content types are expressed through foreign keys and join tables.
WordPress is the most widely used example of a relational CMS. Its content lives in tables like wp_posts and wp_postmeta. Adding a new field to a content type often requires altering the database schema — a process known as a migration.
The relational model excels when data is highly normalised — meaning the same piece of information is stored once and referenced everywhere else. It enforces referential integrity, which prevents orphaned records and ensures consistency across the dataset.
What Is a Document-Based CMS?
A document-based CMS stores each piece of content as a self-contained document — typically a JSON object. There are no fixed tables or columns. Each document can have its own shape, and fields can be added, removed, or restructured without running database migrations.
Under the hood, document-based CMSes use document stores (also called NoSQL databases) such as MongoDB or, in Sanity's case, a proprietary real-time document store. Documents are identified by a unique _id and can reference other documents by that ID — similar to a foreign key, but without enforced constraints at the database level.
Key Differences at a Glance
Schema flexibility: Relational CMSes require schema migrations to change structure. Document-based CMSes allow schema changes without touching the underlying storage.
Data shape: Relational CMSes store flat rows across multiple tables. Document-based CMSes store nested, hierarchical data in a single document.
Querying: Relational CMSes use SQL with JOINs to combine data across tables. Document-based CMSes use query languages like GROQ or GraphQL that traverse document graphs.
Real-time collaboration: Document stores are generally better suited to real-time, concurrent editing because documents are independent units. Sanity's document store is built with real-time sync at its core.
How Sanity Fits In
Sanity is a document-based headless CMS. Every piece of content — whether a blog post, a product, or a page section — is stored as a JSON document in Sanity's Content Lake. The schema you define in your Studio project describes the expected shape of documents, but it is enforced at the application layer, not the storage layer.
This means you can evolve your content model freely: add a new field to a document type and it simply appears on new documents without any migration script. Old documents without that field are still valid — they just return undefined for the missing field, which your frontend can handle gracefully.
Sanity's real-time document store also powers collaborative editing: multiple editors can work on the same document simultaneously, with changes synced instantly across all connected clients.
Imagine you are building a recipe website. You start with a simple content model: each recipe has a title, a list of ingredients, and a body of instructions.
In a Relational CMS
You would create a recipes table with columns for id, title, and instructions. Ingredients would live in a separate ingredients table with a foreign key back to recipes.id. Six months later, when you want to add a nutritional_info JSON column, you run an ALTER TABLE migration — and hope it completes without locking your production database.
In Sanity (Document-Based)
Each recipe is a single JSON document stored in the Content Lake:
{
"_id": "recipe-spaghetti-carbonara",
"_type": "recipe",
"title": "Spaghetti Carbonara",
"ingredients": [
{ "name": "Spaghetti", "amount": "400g" },
{ "name": "Guanciale", "amount": "150g" },
{ "name": "Pecorino Romano", "amount": "100g" },
{ "name": "Eggs", "amount": "4" }
],
"instructions": "Cook pasta al dente. Fry guanciale until crispy...",
"nutritionalInfo": {
"calories": 620,
"protein": "28g",
"carbs": "72g"
}
}Adding nutritionalInfo required no migration. You simply added the field to your Sanity schema definition and started populating it on new and existing documents. Older recipe documents without the field continue to work — your frontend just treats the missing field as optional.
To query all recipes with their ingredients in Sanity using GROQ:
*[_type == "recipe"] {
title,
ingredients,
nutritionalInfo
}No JOINs required. The nested data is already part of the document and is returned in a single query.
"Document-based means no schema"
This is one of the most common misunderstandings. Document-based CMSes like Sanity absolutely have schemas — they are just defined and enforced at the application layer rather than the database layer. In Sanity, your schema is written in JavaScript/TypeScript and governs what the Studio UI presents to editors. The difference is that the storage layer does not enforce the schema, giving you the freedom to evolve it without migrations.
"Relational CMSes are always more reliable"
Reliability depends on the platform, not the storage model. Sanity's Content Lake is a managed, highly available service with built-in redundancy. The document model does not make it less reliable — it simply trades database-level referential integrity for application-level flexibility. For most CMS use cases, this is the right trade-off.
"You can't model relationships in a document-based CMS"
Document-based CMSes support references between documents. In Sanity, a reference field stores the _id of another document, and GROQ's -> operator dereferences it at query time. You can model one-to-many and many-to-many relationships just as you would in a relational system — the mechanics are just different.
"Document-based CMSes don't scale"
Some of the largest content operations in the world run on document-based systems. MongoDB, Elasticsearch, and Sanity's Content Lake are all designed for horizontal scalability. The document model can actually outperform relational databases for read-heavy workloads because there are no expensive JOINs — all related data is co-located in the document.