Files are permanent. Databases are not.

I shipped Textorium to the Mac App Store this week. It’s a native editor for people who write content for static site generators—Hugo, Jekyll, Eleventy. You point it at your project folder, and it shows all your posts in a table. No import. No database. Just files.

Here’s the decision that made everything else easier: files are the source of truth. Not a database. Not a cache. Not a sync process. Just markdown files on disk.

Every time I thought about adding a feature, I asked: does this require storing state outside the markdown files? If yes, I didn’t build it.

That constraint kept the architecture simple. But it’s deeper than architecture. It’s about permanence.

Files outlast systems

A database requires a running system to mean anything. Stop running the database server, and your content is just binary data in proprietary formats. You need that specific software, that specific version, those specific drivers, just to read what you wrote.

Files are different. A markdown file is a text file. You can open it with any text editor. You can grep it. You can version control it with Git. You can copy it to a USB drive and open it on a different machine 10 years from now. The format is readable. The content is portable.

This isn’t just technical. It’s about control.

When your content lives in a database managed by someone else’s platform, you’re dependent on that platform continuing to exist, continuing to let you export, continuing to honor the format they say they use. Every web service promises an export button. Most of them work, until they don’t.

Files don’t require promises. They’re already yours. They’re already readable. They already work with every tool that understands text.

You can print a file

Here’s a test: can you print what you wrote?

Not “generate a PDF from the web view.” Not “export to a format that might print correctly.” Just: select the file, hit print, does it work?

With a file, yes. It’s text. Your operating system knows how to print text.

With a database, no. You need the platform to render the content, style it, convert it to something printable. If the platform goes away, so does your ability to access that content in any meaningful form.

This matters more as time passes. The blog posts you wrote in 2010—can you still read them? If they were in a service that shut down, maybe not. If they were markdown files in a folder, yes. Still there. Still readable.

Static is underrated

“Static” sounds limiting. Databases are dynamic. They respond to queries. They scale. They handle relationships.

But static means stable. It means your content doesn’t change unless you change it. It means you can version control every edit. It means you can diff two versions and see exactly what’s different. It means there’s no hidden state, no background processes rewriting things, no sync conflicts that silently corrupt data.

Static site generators embraced this. Your content is files. Your build process is reproducible. Your output is HTML, CSS, and JavaScript—also just files. The whole pipeline is transparent. You know what’s happening at every step because you can see the files changing.

This isn’t nostalgia for simpler times. It’s recognizing that permanence has value. Files last. Databases don’t. Systems change. Platforms shut down. Formats evolve. But a text file from 1990 still opens today. That’s not a bug. That’s the feature.

What this means for your work

If what you’re writing matters beyond this week, this month, this year—consider: where does it live?

If it lives in someone else’s database, you’re trusting them to preserve it. Maybe they will. Maybe they won’t. Maybe they’ll change their export format. Maybe they’ll add friction to leaving. Maybe they’ll just disappear.

If it lives in files you control, it’s yours. You can move it. You can back it up. You can read it with any tool. You can print it. You can version it. You can trust that it will still be there when you need it.

This isn’t about rejecting databases. They’re useful for live systems, for collaboration, for querying. But for content that matters—for writing that you want to last—files win.

Files are permanent. Databases are not.