Guide
A PHP CMS without a database
Running a CMS with no MySQL sounds like a corner-cutting exercise. It isn't — but it does involve real tradeoffs, and it helps to know them before you commit a client project to one.
What it means. A database-free PHP CMS stores your content as files on disk — JSON, Markdown, or YAML — instead of rows in MySQL or MariaDB. The CMS reads those files, usually building an index in a cache so it isn't hitting the disk on every request. Nothing else about it is unusual: it is still PHP, still server-rendered, still runs behind Apache or Nginx.
What you gain. Four things, and they are more practical than ideological:
- Backups become trivial. A backup is a copy of a folder. With a database you need the files and a consistent dump, taken at the same moment.
- Migration stops being risky. Moving a database-backed site means rewriting URLs inside the database — WordPress's own documentation warns that a naive find-and-replace corrupts serialized data. Moving a flat-file site is a copy.
- Content can live in git. Editorial changes show up in diffs, review in a pull request, and roll back with your code. No database-backed CMS can offer that.
- Fewer moving parts to secure. No database user, no database port, no connection string in a config file, no SQL injection surface.
What you give up. Be honest about this, because it is where people get burned:
- Very large datasets. Hundreds of thousands of entries is where a real database earns its keep. Most of these systems index into a cache to compensate, but there is a ceiling.
- Relational queries. If your content model genuinely needs joins and aggregate queries across large tables, you want SQL.
- Ecosystem size. All of these have smaller plugin catalogues than WordPress, by orders of magnitude.
- Concurrent writes at volume. Files are fine for editorial teams; they are not a transaction engine.
If none of those four is a problem for your project, the flat-file trade is a good one.
The options
4 to consider
-
Free and MIT licensed, with an optional SQLite index for large sites.
Strengths
- No database at all in the default configuration — content is Markdown with YAML front matter, in folders
- Grav 2.0 adds an optional SQLite-backed page index for large sites, which raises the ceiling without requiring a database server
- Five caching layers with Redis, Memcached and APCu drivers
- Free, MIT, and actively developed on PHP 8.3 and Symfony 7
Tradeoffs
- The admin and the REST API are separate plugins, and the API is off by default
- Access groups ship empty; you define them in YAML
- Community support only
-
Text files in folders, with fourteen years of production use behind it.
Strengths
- Content is plain text files; folders map to pages, and the format is human-readable
- No database is used or expected anywhere in the stack
- Multi-language content is handled in core, using a locale infix on the content files
- Fourteen years of continuous releases
Tradeoffs
- Rich content from the block editor is stored as JSON inside a text field, which reduces the diff-friendliness that is otherwise the main draw
- Licensed per site and per domain
- No published guidance on behaviour at large page counts
-
Flat files by default, with a first-party escape hatch to a database.
Strengths
- Markdown with YAML front matter by default, indexed into Laravel's cache
- Uniquely among these, a first-party Eloquent driver can move content into a database later without changing templates or blueprints — the best answer here to the "what if we outgrow it" question
- A genuinely free Core tier
Tradeoffs
- PDO is still a listed server requirement even for a flat-file install
- You are running a Laravel application: Composer on the server, a cache-rebuild on deploy, and a per-minute cron for scheduled content
- The index must be refreshed on deploy or content changes will not appear
-
Total CMS
OursJSON on disk, no database layer in the product at all.
Strengths
- No database code path exists — there is nothing to optionally enable, and no database extension required
- Runs on any PHP 8.2+ host with no Composer, cron, or framework on the server
- Multi-backend caching (APCu, Redis, Memcached, filesystem) with APCu first
- Commercial support, and one vendor for the whole product
Tradeoffs
- No escape hatch — unlike Statamic, there is no way to move content into a database if you outgrow flat files
- Proprietary and paid, with a 45-day trial rather than a free tier
- The smallest ecosystem of the four
How to choose
Three questions settle it faster than a feature comparison:
1. How much content, realistically? Under a few thousand entries, any of these is fine. If you can foresee tens of thousands, look hard at Statamic — it is the only one of the four with a first-party path to move content into a database later without rewriting your templates. If you are already past that, use a database-backed CMS and stop reading.
2. What can the server actually do? If the site will live on whatever shared hosting the client already pays for, Total CMS or Kirby are the safer bets — neither needs Composer, a cron entry, or a framework on the server. Statamic wants a VPS in practice and publishes a list of hosts it does not run on.
3. Is budget the constraint? If yes, Grav is free and MIT and you are not compromising by choosing it.
Adjacent options worth knowing about. If nothing dynamic needs to run on your server at all, a static site generator or a desktop tool like Publii produces plain HTML with no CMS in production — the smallest possible attack surface, at the cost of browser-based editing for your client. And if you only need content delivered over an API to a separate front end, a headless CMS is a different category worth considering on its own terms.
For a fuller head-to-head of these systems including Publii, see our best flat-file CMS roundup.
FAQ
Common questions
Why would I want a CMS without a database?
Mostly for operational simplicity. Backups become a folder copy rather than files plus a consistent database dump; migrations stop involving risky URL rewrites inside a database; content can live in git and roll back with your code; and there is no database user, port, or connection string to secure. The cost is a ceiling on dataset size and a much smaller plugin ecosystem.
Is reading from files slower than a database?
Not in practice, because none of these read every file on every request. They build an index — in APCu, Redis, or the filesystem — and serve from that. A database is faster for complex queries across large datasets, which is precisely the case where you should not be using a flat-file CMS.
How much content is too much?
There is no published hard limit for any of them, and anyone quoting you an exact number is guessing. As a rule of thumb, a few thousand entries is comfortable, tens of thousands needs testing with your actual content and queries, and hundreds of thousands is where a database is the right tool. Statamic is the only one of the four offering a documented migration path into a database.
How do backups work without a database?
You copy the folder — or commit it. That is the whole procedure. With a database-backed CMS the backup must capture the files and a database dump taken at the same moment, or you can restore into an inconsistent state.
Can I really keep content in git?
Yes, and it is one of the strongest practical arguments for flat files. Editorial changes appear in diffs and can be reviewed and reverted like code. Two caveats: rich-text fields that store serialized JSON diff poorly, and if editors are changing content on production you need to decide whether git or the live site is the source of truth — trying to have both is where teams get into trouble.
What PHP version do these need?
As of mid-2026: Total CMS needs PHP 8.2 or later, and Grav, Kirby and Statamic all require 8.3 or later. All four run on standard Apache or Nginx with no database extension required, though Statamic still lists PDO among its server requirements.
Head-to-head comparisons
- Total CMS vs Kirby Kirby is one of the best flat-file CMSs there is, and if its philosophy suits you it is a great choice. The question was never whether Kirby is good — it is whether plain PHP templates and a per-site licence match the way you build. Total CMS answers that differently.
- Total CMS vs Statamic Statamic is excellent, and if your team already lives in Laravel it is probably the natural pick. The real question is whether you want a CMS with a framework attached — because that is the trade, and it cuts both ways.
- Total CMS vs Grav Grav is free, fast, MIT licensed and genuinely well built. If budget decides this, go and use it — you will not be cutting corners. What is left to compare is not capability but how much you want to assemble yourself.
- Total CMS vs WordPress WordPress runs 41% of the web and it earned that. This is not a page about WordPress being bad — its core is well built and its ecosystem is unmatched. It is about what you sign up to maintain, and whether that trade suits the site you are building.
- Total CMS vs Craft CMS Craft is a genuinely good CMS with a free tier we cannot match. It is also the closest thing to Total CMS on this site — same language, same templating, same kind of structured content modelling. Which leaves one real question: should your content live in a database?
- Total CMS vs Webflow Webflow's designer is the best visual building tool there is, and nothing here replaces it. But two questions are worth asking before you commit a client's site to it: what can you actually take with you, and who is Webflow building for now?
- Total CMS vs Squarespace Squarespace is very good at what it does, and for a lot of people reading this it is the right answer. This page is not an argument that you should leave it. It is about what happens if you ever want to.
Details verified on . Software and pricing change — check each product's own site for their current details.
Sources
Verified from each vendor's own documentation on 26 July 2026:
- Grav — requirements
- Kirby — docs and their database guide
- Statamic — requirements and the Eloquent driver
- WordPress — migrating, for the serialized-data warning quoted above
- totalcms.co — our own
All product names and trademarks belong to their respective owners. If anything here is wrong or out of date, tell us and we will correct it.