Why flat files outlive databases

· 2 min read ·Mira Lund

architecture content

Indigo gradient suggesting layered strata

Ask anyone who has migrated a ten-year-old site and they will describe the same afternoon: an export that half worked, entities that meant something in 2016, and a foreign key nobody remembers adding.

The failure mode is silence

Databases fail quietly. A dropped column does not raise an alarm; it simply stops appearing. A folder of text files fails loudly and locally — you open the file and the paragraph is either there or it isn't.

What you actually give up

Being honest about it, flat files cost you three things:

  1. Relational queries. If your content is genuinely a graph, use a database.
  2. Concurrent writes at scale. Two editors saving the same page in the same second is a real problem — file locks help, but they are not a transaction log.
  3. Full-text search over millions of rows. Below a few thousand pages, scanning is fast enough. Above that, index externally.

If none of those three describe your project — and for a portfolio, a magazine or a documentation site they usually don't — the database is a dependency you are carrying for someone else's problem.

What you get back

Version control that means something. git diff on a paragraph reads like a paragraph, not like a binary blob. Backups that are a cp -r. Staging that is a second folder.

And the thing nobody advertises: you can hand the content to a person who does not use your CMS, and they can still read it.