Running a content site without a database

When people talk about scaling a website they usually mean traffic: requests, servers, load balancers. For a content site that is rarely the hard part. The hard part is people — how many of them can change the site without waiting on a developer, and how much they can break when they try.

We run this site with no database at all. Every page, every article, every legal document is a Markdown file with a small block of YAML at the top, sitting in the same Git repository as the code.

Content is just files

There is no posts table. The article you are reading is a file, and its title, description and tags live in the front matter at the top of it:

---
title: 'Running a content site without a database'
tags:
    - statamic
seo:
  title: 'Running a content site without a database'
  description: 'Every page of this site is a Markdown file in Git.'
---

Statamic reads those files directly. That single decision removes a surprising amount of machinery: no migrations, no seeders, no database backups, no staging-versus-production data drift, and no requests to export production content just to work on it locally.

Git is the audit trail

Because content is files, every change is a commit. Who changed a page, when, and what the sentence said before — that is git log, not a bespoke revisions table somebody had to build and maintain.

It also means content and the code that renders it move together. A redesign that changes the shape of an article and the articles themselves land in the same commit, get reviewed together, and roll back together. We have needed that rollback more than once.

Markdown is the only skill required

Markdown is the floor for contributing. You do not need to know PHP, or Git internals, or what a build step is. If you can write, you can write Markdown — and the same file works whether it is edited in a text editor, through a web interface, or by a developer on a branch.

What it costs

This is not free of trade-offs, and it is worth being honest about them.

Flat files stop being the obvious answer once you need to query content the way you query data — filtering thousands of entries across several dimensions, or letting readers search structured fields. Statamic will happily index content for search, but if your "content" is really an inventory, a database is the right tool and you should reach for it.

The other cost is that content edits are deployments. That is a feature when the people writing are comfortable with a repository, and friction when they are not.

For a site whose job is to explain what a company does, the trade is heavily in our favour. There is no admin panel to secure, no database to back up, no credentials to rotate, and no state living anywhere other than the repository.