Why this site has no database

This site is a few folders of Markdown and about three hundred lines of PHP. There's no database. There's no admin panel. To publish an article I write a text file and drop it in a folder. That's the whole system, and I'd argue it's not a compromise — it's an upgrade.

What a database was buying me

The reflex, when building any site that publishes articles, is to reach for a content management system. And a CMS earns its keep when many people edit concurrently, when content is deeply structured, when non-technical authors need a friendly interface. A personal site is none of those things. It's one person, writing prose, occasionally.

For that, a database and an admin login aren't features — they're a standing liability. The admin login is the single most-attacked thing on the internet. The database is a second service to run, patch, back up, and worry about. The CMS itself is a large body of code with a steady drip of security advisories. I was carrying all of it to solve a problem I don't have.

The flat-file alternative

Strip it back to what's actually needed and you get something like this:

site/
├── public/      ← the only thing the web server exposes
│   ├── index.php    (the one script that runs)
│   └── assets/      (css, images)
├── app/         ← code + templates, NOT web-reachable
└── content/     ← the articles, as Markdown files

An article is just a file with a small header:

---
title: Why this site has no database
date: 2026-08-11
summary: One sentence for the index and search results.
tags: web, simplicity
---
The body, in Markdown...

Publishing is save file. Editing is edit file. Version history is whatever you already use for files. There's no "sync", no cache to bust, no migration to run. The content is right there, readable, greppable, and mine in a format that will still open in fifty years.

The security shape comes for free

Notice what the folder layout does. Only public/ is served by the web server. The code lives one level up, in app/; the content in content/. Neither is reachable by any URL — not because a rule forbids it, but because they're outside the door. The most robust access control is the file simply not being where the web server looks.

Then the attack surface audit becomes very short:

• No database → nothing to inject, nothing to steal, no second service to breach.
• No login → the front door everyone kicks at doesn't exist.
• No uploads → no way to smuggle a file onto the box.
• One executable file → I can read it top to bottom and know what it does.

I even wrote the Markdown renderer by hand rather than pull in a library, so there's no third-party code running on the public box at all. That's not purism for its own sake; it's that every dependency is something I'd have to trust and track, and for a job this small I'd rather own the whole thing.

What you give up, honestly

Flat files aren't free of trade-offs. There's no comment system (I don't want one). There's no search across thousands of posts (I don't have thousands). Rendering happens on each request rather than being precomputed — trivial at this scale, though a busier site would cache or generate static HTML. And "just edit a file on the server" assumes you're comfortable with a terminal.

But those are the costs of a large content operation, borrowed by sites that will never be large. For one person writing occasionally, the flat-file version isn't the budget option. It's the one with less to go wrong, less to maintain, and less to lie awake about — which, for something that's meant to sit quietly and last, is exactly the point.