Why Flat Files Beat Databases for Most Publishing Operations

The default assumption in publishing infrastructure is that content requires a database. WordPress, Ghost, Drupal — every major CMS reaches for SQL as its first move. The database stores posts, pages, metadata, user accounts, settings, revisions. It becomes the system's center of gravity, and everything else orbits it.

The assumption is rarely examined. For most publishing operations it is also wrong.

A database solves a specific problem: concurrent writes from multiple sources, relational queries across large datasets, transactional integrity under load. A solo publisher or small editorial operation does none of these things. Content is written sequentially, published infrequently relative to how often it is read, and structured simply — title, date, body. The database is solving a problem that does not exist.

Flat files solve the actual problem. A Markdown file is readable without tooling, editable in any text editor, versionable with Git, portable across any system, and trivially backed up. It has no connection pool to exhaust, no schema to migrate, no credentials to rotate, and no service to restart. It existed before the CMS and will exist after it.

The objection is always search and querying. How do you find all posts tagged with a given term? How do you sort by date? These operations require indexes. But indexes can be built at compile time rather than query time. A static site generator reads the files, builds the index once, and writes it to HTML. The reader gets a pre-computed result served from a CDN edge node in milliseconds, with no database query in the path at all.

The database is a runtime dependency. Flat files are not. Every runtime dependency is a potential failure point, a maintenance burden, and a cost. Removing it is not a limitation of the system. It is a clarification of what the system actually needs to do.