Flat-File CMS vs Database CMS: Which to Pick in 2026

Every CMS decision starts with one question nobody asks out loud: where does the content actually live? Pick wrong and you'll either fight git merge conflicts with your marketing team or watch a 5,000-post archive crawl because every page load greps a folder of Markdown files.

This is the flat-file CMS vs database CMS decision, and it matters more than which admin UI looks prettier.

TL;DR: Flat-file CMS (Grav, Kirby, Statamic in flat mode, Decap) store content as files in your repo — you get git history, trivial backups, and zero database setup. Database CMS (WordPress, Craft, Ghost, UnfoldCMS) store content in MySQL/SQLite/Postgres — you get fast queries, real relationships, and editing that doesn't require git. Our stance: flat-file wins for small developer-only sites and docs under ~500 pages. Database wins the moment you have non-technical editors, more than ~1,000 content items, or content that references other content. Full disclosure: we build UnfoldCMS, a database-driven CMS — and we'll still tell you where flat-file genuinely beats us.

What's the actual difference between flat-file and database CMS?

A flat-file CMS stores each piece of content as a file on disk — usually Markdown with YAML front matter. A database CMS stores content as rows in tables, queried through SQL. The storage model decides everything downstream: versioning, search, editing workflow, hosting, and how the system behaves at 10 items vs 10,000.

In a flat-file system like Grav or Kirby, a blog post is literally content/blog/my-post/item.md. The file is the database record. Folder structure defines hierarchy. Front matter holds metadata. Deploy means git push.

In a database CMS, a post is a row in a posts table with foreign keys to authors, categories, and media. The file system holds code and uploads; content lives behind a query layer.

Static site generators (Hugo, Jekyll, Eleventy) sit adjacent to flat-file CMS — same file-based storage, but no runtime at all. They compile files to HTML once at build time. Git-based headless tools like Decap CMS put an editing UI on top of files in a repo. Different tools, same storage philosophy: content is files.

Neither model is "more modern." Flat-file feels newer because of the JAMstack wave, but file-based content predates databases. The question is which tradeoffs fit your project — and that's what the rest of this post works through, dimension by dimension. If you're still earlier in the decision (CMS at all vs plain Markdown), read Markdown vs CMS for docs first.

Where flat-file genuinely wins: version control

Flat-file CMS win content versioning outright, and it's not close. Every edit is a git commit: full diff history, blame, rollback to any point, branches for draft rewrites. Most database CMS — including UnfoldCMS — have no revision history at all. Once you save over a post, the old version is gone.

This deserves to be stated plainly because vendors (us included) tend to mumble past it. With Grav or a Hugo site in git, you can answer "what did this pricing page say on March 12?" in one command. With WordPress you get a basic revisions table (it works, but it bloats the database and diffs poorly). With Ghost, Craft (without plugins), and UnfoldCMS, you get nothing — the previous body is overwritten.

Our honest take as a database CMS vendor: if your content is legally sensitive, frequently reverted, or maintained like code (API docs, changelogs, policy pages), git-backed content is a real advantage, not a nice-to-have. We mitigate the gap with slug history (old URLs keep resolving after a rename) and database backups, but a backup is a snapshot, not a diff. Restoring one post from last Tuesday means restoring the whole database or digging through SQL dumps.

Flat-file also wins review workflow for technical teams. A content change can go through a pull request — comments, approvals, CI checks that lint for broken links. No database CMS gives you that natively.

Where database CMS wins: querying, relationships, and scale

Database CMS win the moment content needs to be queried, related, or counted. "Show the 10 newest posts in category X by author Y, excluding drafts" is one indexed SQL query. In a flat-file system, it means parsing front matter across every file — fine at 200 files, painful at 2,000, brutal at 20,000.

Flat-file systems handle this with caching, and at small scale it works well — Grav's page cache is genuinely fast. But cache invalidation gets hairy as content grows, and some operations resist caching entirely:

• Full-text search. A database CMS searches with indexed queries out of the box (UnfoldCMS uses Spatie Searchable over MySQL/SQLite — title, body, and description, no Elasticsearch needed). Flat-file sites usually bolt on a client-side index (Lunr, Pagefind) that ships your entire searchable corpus to the browser, or pay for Algolia.
• Relationships. "Related posts," "all articles by this author," "products in this collection" are foreign keys in a database. In flat-file land they're front-matter ID references you maintain by hand — rename a file and nothing warns you the reference broke.
• Aggregation. Comment counts, view counters, "most read this month" — anything that writes data at request time fights the flat-file model, because writing to files on a live server is how you get race conditions.

The crossover point in our experience is around 1,000 content items. Below that, flat-file performance and ergonomics hold up fine. Above it, file-scanning costs and reference fragility compound, and you end up rebuilding database features on top of files — at which point, use a database.

If you want a structured way to score these tradeoffs for your own project, our guide on how to evaluate a CMS beyond the marketing page has a worksheet for exactly this.

What about non-technical editors?

This is the decision point that overrides everything else: if non-developers edit content, a database CMS with a real admin UI wins. Asking a marketer to write YAML front matter, run git, and resolve a merge conflict isn't a workflow — it's a support ticket generator. Editor experience is where flat-file setups quietly die.

Flat-file vendors know this. Kirby's panel and Statamic's control panel are genuinely good editing UIs over files — credit where due, Statamic's is one of the best admin panels in PHP. Decap puts a web editor on a git repo so writers never see a terminal. These close most of the gap for a single careful editor.

Where they don't close it: multi-author concurrency. Two editors saving the same file means last-write-wins or a git conflict surfaced to someone who doesn't know what <<<<<<< HEAD means. Database CMS handle concurrent sessions natively — row-level writes, per-field updates, no merge step. They also give you the operational features editorial teams expect: scheduled publishing that fires on its own (UnfoldCMS runs this off a single cron line, no queue worker), draft states, role-based permissions, and comment moderation queues.

Building a content workflow for an actual team? See what a database-backed editorial setup looks like in practice — browse UnfoldCMS features or click around the live demo, no signup needed.

Comparison table: flat-file vs database CMS across 8 dimensions

Two clarifications on that last row. First, "needs a database" sounds heavier than it is in 2026: SQLite is a single file, needs zero setup, and UnfoldCMS runs on it on plain shared hosting. Second, static generators (Hugo/Jekyll) are even lighter than flat-file CMS — pure CDN hosting — but they're build tools, not CMS; every content change is a rebuild and redeploy.

How do you actually decide? A 5-step checklist

Work through these in order — the first "yes" usually settles it:

1. Will anyone non-technical edit content? Yes → database CMS. This outranks every other factor. (Statamic/Kirby panels are the partial exception if you have exactly one patient editor.)
2. Will you pass 1,000 content items in two years? Yes → database CMS. Count realistically: posts, pages, docs, landing pages, translations.
3. Does content reference other content? Authors, related posts, product-to-category links, anything you'd model with a foreign key → database CMS.
4. Is the content maintained like code? Docs, changelogs, legal pages where diff history and PR review matter more than editing comfort → flat-file or a static generator wins.
5. Still tied? Default to whichever your team already operates. A Laravel shop should pick a database CMS over learning Grav's lifecycle; a JAMstack team should stay in git.

The pattern behind the steps: flat-file optimizes for the developer maintaining content, database optimizes for the team producing content. Solo dev blog, project docs, portfolio — flat-file or Hugo is the right call and we'll say so. Marketing site with a content calendar, multi-author blog, anything with editors who don't commit code — database, every time.

There's also a hybrid worth knowing: a database CMS with a REST API feeding a static front end. You keep the editor-friendly admin and queryable content, and ship static pages — UnfoldCMS exposes everything at /api/v1/* and can fire signed webhooks to trigger a Netlify or Vercel rebuild on publish. For more self-hosted options on both sides of this divide, see our self-hosted CMS platform roundup.

When each one wins: the short version

Pick flat-file when the site is small, developer-maintained, and benefits from git: docs sites, personal blogs, project microsites, anything under ~500 pages with zero non-technical editors. Pick a database CMS when editors outnumber developers, content items pass four digits, or content is relational — which describes most business sites.

Concrete pairings, including competitors we respect:

• Project docs, solo dev blog → Hugo or Eleventy if you don't need a runtime; Grav if you want one without a database.
• Designer/agency site with one careful editor → Kirby or Statamic. Their panels are excellent and the file-based model keeps client handoff simple.
• Multi-author blog or content-led marketing site → database CMS. Ghost if it's purely a newsletter-blog; WordPress if you need its plugin ocean; UnfoldCMS if you want Laravel + React and shared-hosting deployment — see what's included at each tier.
• Headless front end (Astro/Next) with editors → database CMS with an API and rebuild webhooks, or Decap if editors are technical-adjacent and content is small.

If you're self-hosting either way, the complete self-hosted CMS guide covers the operational side — backups, updates, and hosting — for both models.

Want to feel the database side before committing? Spin through the UnfoldCMS demo — real admin, real content, two minutes.

FAQ

Is a flat-file CMS faster than a database CMS?

At small scale, usually yes — reading a cached file beats a query round-trip, and there's no connection overhead. Past roughly 1,000 items the curve flips: indexed SQL queries stay near-constant while file scans grow linearly. For most sites under 500 pages, both are fast enough that hosting quality matters more.

Can I use git for version control with a database CMS?

Only for code and templates, not content. Content lives in the database, so git never sees it. Workarounds exist — scheduled SQL dumps committed to a repo give you coarse snapshots — but you lose per-edit diffs and easy single-post rollback. If per-edit content history is a hard requirement, that's a genuine reason to choose flat-file.

Do flat-file CMS work for blogs with multiple authors?

They can, but friction grows with each author. Two people editing the same file produces git conflicts or silent overwrites, and non-technical authors need a UI layer (Statamic's panel, Decap) to avoid touching files directly. Past two or three regular authors, a database CMS with concurrent editing and roles is the calmer choice.

Is WordPress a flat-file or database CMS?

Database — it stores all content in MySQL/MariaDB and has since 2003. It's also one of the few database CMS with built-in revisions, though stored revisions bloat the posts table over time. Flat-file alternatives in the PHP world include Grav, Kirby, and Statamic running in flat mode.

Sources and methodology

• Storage and feature claims for Grav, Kirby, Statamic, Decap, Hugo, Ghost, Craft, and WordPress are based on their official documentation as of June 2026.
• UnfoldCMS claims (SQLite/MySQL support, Spatie Searchable DB search, scheduled publishing via cron, /api/v1/* REST API, publish webhooks, slug history, no post revisions) are verified against the UnfoldCMS codebase, June 2026.
• The ~1,000-item crossover is our working heuristic from building and migrating content sites, not a benchmark — your numbers will vary with caching, hosting, and content size.
• Disclosure: this post is written by the UnfoldCMS team. We build a database-driven CMS and have flagged the dimensions where flat-file tools beat us, including content versioning.