How we ran krodox.com 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.

This is how we ran krodox.com, our old site, with no database at all. Every page, every article, every legal document was 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 was no posts table. An article was a file, and its title, description and tags lived in the front matter at the top of it:

---
title: 'How we ran krodox.com without a database'
tags:
    - statamic
seo:
  title: 'How we ran krodox.com without a database'
  description: 'Every page of our old site was a Markdown file in Git.'
---

Statamic read those files directly, and it still ran its control panel with a single user account, but the content itself always lived in the Markdown files in Git. That single decision removed 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 was files, every change was a commit. Who changed a page, when, and what the sentence said before: that was git log, not a bespoke revisions table somebody had to build and maintain.

It also meant content and the code that renders it moved together. A redesign that changed the shape of an article and the articles themselves landed in the same commit, got reviewed together, and rolled back together. We needed that rollback more than once.

Markdown is the only skill required

Markdown was the floor for contributing. You did 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 worked whether it was edited in a text editor, through the control panel, 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 was to explain what a company does, the trade was heavily in our favour. There was no database to back up, no content hiding in tables, and no state living anywhere other than the repository.