Most people never question it. A CMS means a database, by default.
A normal WordPress page does real work before anyone sees it. PHP asks a MySQL database for the page. The database answers. PHP assembles the final page from that answer. Only then does a visitor see anything.
This happens on every visit, even when the page has not changed in a year.
Most business websites do not change on every visit. A pricing page, a blog post, an about page: these stay the same for weeks or months at a time. A database that rebuilds the page from scratch, on every request, is solving a problem the page does not have.
WordPress is not alone here. Sanity, Contentful, and most modern CMS platforms store your content the same way underneath: as rows in a database, reachable only through that vendor's API. The rendering model differs. The dependency does not. Your words, your images, your product descriptions: all of it lives inside a system you cannot open directly and cannot fully leave.
Even WordPress community agrees with this, in a roundabout way. Full-page caching plugins exist for one reason. They take a page the database rebuilds every time and turn it into something closer to a static file. That is the format the page should have been in from the start.
The alternative already has a name
A file-based CMS stores content the plain way: as Markdown, JSON, or HTML files, sitting in a folder. Not as rows in a database, reachable only through one vendor's API.
Put those same files inside a Git repository and the category gets a second name: Git-based CMS, or Git-backed CMS. Git is the version control system that already runs under most of the world's software. Decap CMS, TinaCMS, Keystatic, and Sveltia CMS all build on it today. None of them need a database to run.
Git already gives you what the database was for
The usual objection is fair: a website needs drafts, review, and a way to undo a mistake. That is what a database and its admin panel are for.
Git already does all three, natively, for free. Every save is a commit, with a name, a time, and an exact record of what changed. A new page can live on its own branch until someone approves it. You can undo any change, on any file, by going back to the commit before it. This is not a workaround. It is the same system that already manages the code for most of the software you use.
The real gap in file-based CMS was never control. It was the interface. Knowing what a commit is, or what a branch is, or how to format a Markdown file just right, is a fair ask for a developer. It is not a fair ask for a marketer fixing a typo on a Tuesday.
That gap does not need a database to close it. It needs a better interface sitting on top of Git, not instead of it. Git-backed, not Git-exposed: the same history and control, with none of the command line.
The second reason: AI agents read files, not databases
There is a second reason file-based CMS is spreading, and it has nothing to do with cost or speed.
Every large language model is trained on the open web and on public code. That training data is built mostly from HTML, CSS, JavaScript, Markdown, JSON, and Git history: commits, diffs, folders. This is the native language of every AI agent in use today.
No model was trained on the inside of your specific WordPress database, or your Sanity project's private schema. An agent that wants to help you edit that content has to go through a custom integration built for that one system: a plugin, an API, a set of docs someone wrote by hand. Every one of those is a translation step, and every translation step is a place for something to go wrong.
Point the same agent at a folder of Markdown files in a Git repository, and there is no translation step. The agent reads exactly what is there, the same way it reads any other file on the open web it was trained on.
None of this means a database is always the wrong choice. A product catalog with a million SKUs, or an application with real user accounts, needs one. A marketing site, a blog, or a set of documentation pages, the kind most businesses actually run, does not.
This is already how a Splitleaf site works
A Splitleaf site is already built this way. Every page is a real file. Every change is a real Git commit, to your own GitHub repository, not to a database we control. No proprietary format stands between your content and the person, or the agent, trying to read it.
The part we built is the interface. You, or your marketing team, never see a commit, a branch, or a line of Markdown, HTML, or CSS, unless you go looking for it. That was always the missing piece. Not a database. Not more control. Just a good way in.