Your Blog Doesn’t Need a Database (And Neither Does Most of Your Infrastructure)
I’ve been keeping servers alive since 1998. That’s 27 years of watching trends come and go, of seeing “best practices” become worst practices, of watching the industry relearn lessons we already learned the hard way.
Here’s what I’ve figured out: we’re overcomplicating everything.
The setup that prompted this rant
This blog runs on:
- One Go binary (5000blogs)
- Markdown files
- nginx as a reverse proxy
- Let’s Encrypt for SSL
No database. No Docker swarm. No Kubernetes. No “serverless” functions calling other functions. Just files and a simple binary that serves them.
And you know what? It’s more reliable than most “production-grade” setups I’ve seen.
The Y2K lesson we forgot
I started in this field right before Y2K. Remember that? The world thought planes would fall from the sky because of two-digit years. What did we learn?
Simple systems are easier to fix.
When you have a database, a cache layer, a message queue, three microservices, and a Kubernetes ingress controller between your user and your content, you have seven things that can break. When you have a binary serving files, you have one thing that can break.
I’ve seen companies with 50-person engineering teams struggle to keep their blogs online. Meanwhile, this setup? I could debug it in my sleep.
“But what about scale?”
Oh, please.
Your blog gets how many hits? Hundreds? Thousands? Maybe tens of thousands if you write something that resonates?
A single $5 VPS can serve millions of requests per day with a setup this simple. Nginx is battle-tested. Go is fast. Static files are the ultimate cache. You’re not Netflix. Stop architecting like you are.
The real question isn’t “can this handle scale?” It’s “can I understand and fix this at 3 AM when I’m half asleep?”
The physics of it
I have a physics degree. Not computer science — physics. And you know what physics teaches you? Complex systems fail in complex ways.
The universe tends toward entropy. Every component you add, every abstraction layer, every “service” that’s supposed to make your life easier — they’re all potential failure points. Energy (and attention) gets dissipated across them.
A simple system is like a low-energy state. Stable. Predictable. Boring in the best possible way.
On “serverless”
Can we talk about this word for a second?
“Serverless” doesn’t mean there are no servers. It means you don’t control the servers. Someone else does. And they’re charging you rent, lock-in fees, and the occasional surprise bill when your function gets called too many times.
Meanwhile, my “serverful” setup costs $5/month, runs on hardware I control, and I can move it anywhere in about 10 minutes. rsync the files, install nginx, done.
Why plain text matters
Here’s the thing about markdown files: I own them.
They’re not in some proprietary database format. They’re not locked in a CMS that might get acquired and shut down. They’re not in a cloud service that could change their pricing tomorrow.
They’re just text. Portable. Searchable. Version-controllable. I could move this blog to Hugo, Jekyll, or a completely custom solution in an afternoon. Try doing that with WordPress or Medium.
The maintenance burden
People think simple setups are “not production-ready.” Let me tell you about production.
Production is the thing that wakes you up at night. Production is the database that needs vacuuming, the cache that needs warming, the service mesh that needs… whatever service meshes need.
This blog? I update the SSL cert every 90 days (automated). I update the binary when 5000blogs ships improvements (took me 5 minutes today). That’s it.
The complexity budget is near zero. My attention can go to writing instead of maintaining.
What this isn’t
I’m not saying everything should be this simple. If you’re running a SaaS with real-time collaboration, multiple data centers, compliance requirements — yeah, you need more moving parts.
But most of us aren’t. Most of us need:
- A blog
- A portfolio site
- Documentation
- A personal wiki
And for that? You don’t need a database. You don’t need microservices. You don’t need Kubernetes.
You need files and something to serve them.
The counter-argument I hear
“But Toni, this doesn’t scale to team workflows! What if multiple people need to edit?”
Git. The answer is git. It’s 2026 and we’re still pretending that collaborative editing needs a web interface when we have the most sophisticated distributed version control system ever invented.
Write in markdown. Commit to git. Push. Deploy. It’s not just simple — it’s better than most CMS workflows because you get versioning, branching, and rollback for free.
In conclusion
The best system is the one you understand completely. The one you can fix when it breaks. The one that doesn’t wake you up at night.
Sometimes that means using boring technology. Sometimes that means ignoring the hype. Sometimes that means admitting that a physics major from 1998 knew something that modern “cloud architects” forgot.
Simple isn’t just good. Simple is reliable.
And reliable is what matters when you’re 27 years into a career and you’ve seen too many over-engineered systems crash and burn.
This post was written in plain markdown, committed to git, and served by a single Go binary. No databases were harmed (or used) in its creation.