Database vs Flat-File CMS Performance: What Actually Makes a Site Fast (2026)

"Flat-file is always faster than a database." You've probably read this in a Hacker News thread, nodded, and filed it away as fact. It isn't. A flat-file CMS reading 40 markdown files off disk on every page load can be slower than a database CMS that answers the same request from a warm cache in under a millisecond. The file-versus-database question is real, but it's rarely the thing that decides how fast your site feels. Caching and rendering strategy are.

This post breaks down what a flat-file CMS actually is, what a database CMS actually is, where each one wins and loses, and why the "flat-file wins by default" claim falls apart the moment your site grows past a few dozen pages. We'll look at SQLite as the middle ground — a single portable file that still gives you indexes — and end with a short decision checklist so you can pick architecture based on your real workload instead of a forum myth.

TL;DR

Flat-file CMS stores content as files (markdown, YAML, HTML) with no database — think Grav, Kirby, or a Hugo static build. A database CMS stores content in MySQL, SQLite, or Postgres. Neither is automatically faster. An uncached database query is slow, but a cached database CMS — or a statically built site — beats reading and parsing dozens of files at scale. Flat-file wins on tiny sites, git-based workflows, and zero database ops. It loses on search, relations, thousands of entries, and concurrent writes. Database wins on querying, relations, and scale, especially with caching turned on. SQLite sits in the middle: one portable file plus real indexes. The real speed lever is caching and how you render pages — not the storage engine. UnfoldCMS is a database CMS that runs on either SQLite or MySQL, so it spans that whole range from single-file simplicity to full server database.

What is a flat-file CMS?

A flat-file CMS keeps all content in plain files on disk. Each post is a markdown or YAML file, sometimes with a front-matter block for metadata. There's no database to install, migrate, or back up separately. Grav, Kirby, and static generators like Hugo and Eleventy are the common examples.

The appeal is real. Your content lives in a folder you can commit to git. You can edit a post in any text editor, diff changes line by line, and roll back with git revert. Deployment can be as simple as copying files. For a personal blog or a docs site with 30 pages, that workflow is hard to beat — and the flat-file vs database CMS comparison breaks down more of these tradeoffs.

But "no database" doesn't mean "no work at request time." On every page load, a flat-file CMS may scan a content directory, read multiple files, parse front matter, and render markdown to HTML. Without caching, that filesystem work grows linearly with your content.

What is a database CMS?

A database CMS stores content in structured tables — MySQL, Postgres, or SQLite. Content, metadata, categories, and relationships live in rows and columns you query with SQL. WordPress, Drupal, Statamic (in its database mode), and UnfoldCMS work this way.

The database buys you structure. You can ask "give me the 10 newest posts in the Tutorials category, sorted by date, that mention SQLite" and get an answer in one indexed query. Doing the same across a folder of flat files means opening and scanning every file yourself. See our note on SQLite vs MySQL for a CMS for how the two database engines compare.

The catch people fixate on: a database query has overhead. Connecting, planning the query, reading from disk or memory — it adds up. An uncached query on a busy site under load can be the slow part of your request. That single fact is where the whole "flat-file is faster" myth comes from. It's true only in the narrow, uncached case.

Is a flat-file CMS really faster?

Not automatically. A flat-file CMS avoids database overhead but pays filesystem and parsing cost on every uncached request. A cached database CMS answers from memory in well under a millisecond. Past a few dozen entries — or under concurrent traffic — a cached database or a static build usually wins. Raw file reads don't scale the way people assume.

Here's the mechanism. Reading one small file is fast. Reading 40 files, parsing YAML front matter in each, and building an index of them so you can sort by date — that's slow, and it repeats on every request unless you cache the result. A database does that indexing once, keeps it in memory, and reuses it. So the honest comparison isn't "file read vs SQL query." It's "uncached file scanning vs a warm query cache." Framed that way, the database often wins.

What actually makes a CMS fast?

Caching and rendering strategy — not the storage engine. A cache turns any expensive lookup, file read or SQL query alike, into a near-instant memory hit. Serving pre-rendered HTML skips content processing entirely. These two levers move page speed far more than the choice between files and a database ever will.

Think about where time goes on a page request:

1. Reading content — from files or a database. Milliseconds, usually the smallest slice once anything is cached.
2. Parsing and rendering — markdown to HTML, template compilation, front-matter parsing. Often the real cost on flat-file setups.
3. Application overhead — framework boot, routing, middleware. Fixed cost you pay regardless of storage.
4. Caching layer — config, route, view, and application caches that skip steps 1 through 3 on a hit.
5. Delivery — HTML down the wire, plus your Core Web Vitals on the frontend, which no backend choice can fix on its own.

A database CMS with warm config, route, view, and app caches spends almost no time on steps 1 and 2. A flat-file CMS without a render cache pays steps 1 and 2 on every hit. That's why caching, not storage, is the lever that matters.

Where does flat-file win?

Flat-file wins on small, simple, git-driven sites. No database means no database ops — nothing to install, tune, back up, or migrate. Content lives in version control, so history and rollback come free. For a blog, a docs site, or a landing page with a handful of contributors and low write volume, that simplicity is a genuine advantage.

The sweet spot is a site where content is written by developers, changes go through git, and total page count stays in the low hundreds. You get atomic deploys, easy local development, and a content model you can read in a text editor. No connection strings, no SELECT statements, no schema migrations. If that's your workflow, flat-file removes a whole category of operational work.

Flat-file also pairs naturally with static site generators. Build the whole site to HTML once, serve it from a CDN, and every page is already rendered. At that point you've sidestepped the database-versus-files question entirely, because nothing runs at request time.

Where does flat-file lose?

Flat-file struggles with search, relationships, scale, and concurrent writes. Full-text search across files means scanning everything, since there's no index. Relations like "posts in this category tagged X" force you to load and filter files by hand. At thousands of entries the filesystem work balloons, and two editors saving at once can clobber each other with no row-level locking.

Search is the sharpest pain. A database answers WHERE body LIKE '%query%' or a full-text index instantly. A flat-file CMS has to open and scan every file, or maintain a separate search index you now have to keep in sync — which quietly reintroduces the complexity you left the database to avoid.

Relations are the second pain. "Show related posts that share two tags and exclude drafts" is one query in SQL. Across flat files it's a loop that loads everything into memory and filters in application code. That's fine at 50 posts and painful at 5,000.

Is SQLite the best of both worlds?

Often, yes. SQLite is a full SQL database that lives in a single file. You get real indexes, fast queries, relations, and full-text search — but the whole database is one portable file you can copy, commit, or ship like any other asset. It's nearly as simple to move as flat files, with none of the scan-everything overhead.

That's why SQLite blurs the line the myth depends on. It's a database, so you get indexed queries and proper search. It's a single file, so there's no separate database server to run, no connection pool to tune, no second backup target. For read-heavy sites — most content sites — SQLite is fast and operationally light. Its main limit is concurrent writes: it locks the file per write, so a site with heavy simultaneous editing or high write throughput is where you'd reach for MySQL or Postgres instead.

UnfoldCMS runs on either SQLite or MySQL, so you can start with the single-file simplicity of SQLite and move to MySQL when write concurrency or scale demands it — without changing CMS.

Flat-file vs SQLite vs MySQL: how do they compare?

Here's the tradeoff across the four things that actually matter. Speed assumes caching is in place; without caching, all three degrade and rendering strategy dominates.

Read this as a spectrum, not three separate camps. Flat-file and MySQL sit at the ends. SQLite sits in the middle and, for a lot of content sites, is the pragmatic default — database power with flat-file portability.

What should you actually do?

Pick based on your real workload, then make caching non-negotiable. Use these rules:

• Under ~200 pages, git workflow, developer authors, low writes? Flat-file or a static build is a clean fit. Enjoy the simplicity.
• Need search, relations, categories, or non-technical editors? Use a database. This is most real sites.
• Read-heavy content site that wants database power without database ops? Start on SQLite. Move to MySQL only if write concurrency becomes a problem.
• High write concurrency, huge catalogs, or heavy multi-editor use? MySQL or Postgres. This is where flat-file and SQLite both hit limits.
• Whatever you pick, turn on caching. Config, route, view, and application caches are what make a database CMS fast. Skipping them is how the "databases are slow" myth stays alive.

Before you commit, decide what to measure. Time to first byte under load, query count per page, and cache hit rate tell you more than a synthetic single-request benchmark. Our guide on CMS performance benchmarks and what to test covers the metrics that actually predict real-world speed.

One more path worth naming: you can use a database CMS as a headless backend and render a static frontend from it. You get structured content, search, and relations in the admin, plus pre-rendered pages at the edge. UnfoldCMS can run that way too — database for authoring, static or cached delivery for speed. You don't have to choose between the two models. You can see the full feature set here.

FAQ

Does a flat-file CMS need caching too? Yes. Without a render or page cache, a flat-file CMS re-reads and re-parses content files on every request. Caching helps flat-file setups just as much as database ones — it's the shared lever, not a database-only fix.

Is SQLite too small for a real website? No. SQLite handles read-heavy sites into the tens of thousands of entries comfortably. Its limit is concurrent writes, not reads or size. Many production content sites run on SQLite without issue.

Will switching from database to flat-file speed up my slow site? Probably not. If your site is slow, the cause is usually missing caching, heavy rendering, or unoptimized queries — not the storage engine. Fix caching first; you'll likely find the storage choice wasn't the bottleneck.

Can I move from SQLite to MySQL later? With a CMS that supports both, yes. UnfoldCMS runs on either, so you can start on SQLite and migrate to MySQL when write concurrency or scale calls for it, without switching platforms.

What about static site generators — where do they fit? A static build renders every page to HTML ahead of time, so nothing queries files or a database at request time. It's the fastest delivery model for content that doesn't change per-request, and it can be fed by either flat files or a headless database CMS.

Ready to stop guessing about performance?

If you're choosing CMS architecture, don't let a forum myth pick for you. A database CMS with caching is fast, portable on SQLite, and scalable on MySQL — and UnfoldCMS gives you both engines plus Laravel's caching out of the box, whether you render server-side or use it as a headless backend for a static frontend. Explore the features and pick the model that fits your workload.

Sources note: This post draws on general, well-documented behavior of flat-file CMSs (Grav, Kirby, Hugo), SQLite, and MySQL, plus standard web-performance principles around caching and rendering. Benchmark figures depend heavily on hardware, content volume, and cache configuration — test on your own workload before committing to an architecture. No UnfoldCMS-specific benchmark numbers are claimed here.