Open the top twenty CMSes by installs and nineteen of them put your writing in MySQL or Postgres.

Nobody chose this recently. It was chosen once, around 2003, when the alternative was writing files with PHP and the shared hosting of the day made a database the reliable option. Everything since has inherited it.

It is worth being fair about what the database buys, because it is not nothing.

Querying. Show me posts in this category, published, newest first, twenty at a time. Doing that over a directory of files means either walking the directory on every request or building an index, and building an index means building half a database.

Concurrency. Two editors saving at once is a solved problem in a database and an unsolved problem in a filesystem, where the usual outcome is that the second save silently wins.

Referential integrity. If a post points at an author and the author is deleted, a database can refuse or cascade. Files just end up pointing at nothing.

Now the costs, which are quieter.

Your content is in a format you cannot read. It is in a table, in a database, in a proprietary-enough dump format, and the only thing that understands it is the CMS that put it there. WordPress makes this worse by serialising PHP arrays into single columns, so even with the database in front of you some of it is opaque.

You cannot diff it. There is no meaningful review of a content change, no branch, no history that a person can read. Every CMS eventually grows a revisions table and it is always worse than git, because it is reimplementing git badly inside a table.

Backup is a separate ritual from the code. The code is in version control and the content is in a dump somebody hopefully automated. The two drift, and restoring to a consistent point means matching a database snapshot to a commit by timestamp and hoping.

And it is a service to run. A database is a process with a memory profile, an upgrade path and a failure mode.

The alternative is files, and it has been tried repeatedly. Kirby and Statamic and Grav all store content as files on disk and are perfectly serious pieces of software. What they give up is exactly the list above: querying at scale, concurrent writes, integrity. What they get is content you can read with cat, diff in a pull request and back up with tar.

There is a newer entry on that list. The tools I write with read files. An agent can open a content tree, grep it, follow a reference from one document to another, and hand a change back as a diff that gets reviewed like any other. Pointed at a database, the same tool needs an API in front of it before it can see anything at all, and what comes back is a row rather than a document. The properties that make content workable for a person are the ones that make it legible to a machine that writes, and neither was designed with the other in mind.

The interesting part is that the trade is not fixed. You can store files as the truth and build an index over them for querying, which gets you most of the database benefits without moving the content into it. The index becomes a cache, and a cache can be deleted and rebuilt, which is a much less frightening object than a database holding the only copy of your writing.

That is not a novel idea. It is how a search engine relates to a filesystem and how a package manager relates to a repository. It just has not been the default in this corner of software, and I have not seen a convincing argument for why not.