Skip to content
● Grav 2.2 is out: 2x faster cold starts and 96% less memory on big sites. Read the announcement →
journal 10 mins

Grav vs WordPress: An Honest Comparison

Where each one wins, where each one hurts, and how to pick

I co-founded Joomla, I created Grav, and I've spent more than twenty years building sites on PHP content management systems. So I get asked one question more than any other: "Should I use Grav or WordPress?"

My honest answer is that it depends on the site. But for most of the sites people actually build (marketing sites, documentation, portfolios, small business sites, personal blogs), I think Grav is the better tool. And for a few kinds of site, WordPress is the better tool, and I'll tell you which ones.

This is the first post in a series comparing Grav with other platforms. WordPress goes first because it's the one everyone already knows.

The Big Difference: Where Your Content Lives

Everything else in this comparison follows from this one point.

WordPress keeps your site in a MySQL (or MariaDB) database. Your posts and pages live in the wp_posts table, your settings in wp_options, your menus and widgets spread across a few more tables. Your uploaded images sit on disk, but everything that describes them is in the database too. To see your content, you need WordPress running, or a database tool.

Grav has no database at all. Your content is a folder of plain text files:

TEXT
user/pages/
├── 01.home/
│   └── default.md
├── 02.blog/
│   ├── blog.md
│   └── my-first-post/
│       ├── post.md
│       └── header.jpg
└── 03.contact/
    └── form.md

Each page is a Markdown file with a little YAML at the top for its settings:

MARKDOWN
---
title: My First Post
date: 10/16/2026
taxonomy:
    tag: [news]
---

This is my first post. The image sits **right next to it** in the same folder.

That sounds like a small detail. It isn't. Here's what it means day to day:

  • Backups are a copy of a folder. Zip it or rsync it somewhere safe.
  • Version control works out of the box. Put your user/ folder in Git and you get a full history of every change, plus the option to deploy with a git push.
  • Moving hosts is copying files. No database export, no search and replace on serialized URLs.
  • Staging sites are a second copy of the folder. No syncing two databases.
  • Editing outside the CMS is allowed. Open a page in VS Code, change it, save it, and the site updates.

With WordPress, every one of those jobs is possible. But each one usually needs a plugin or a hosting feature to do it well.

Speed

A WordPress page view runs a stack of database queries and loads every active plugin before it sends a byte. On a busy site you fix that with a caching plugin, an object cache like Redis, or managed hosting that does the caching for you. That works fine. But it's another moving part, and a cached WordPress site that serves a stale page after an edit is a familiar headache.

Grav compiles your pages and caches the result on its own, with no setup. Grav 2.2 made that a lot faster: cold starts are about twice as fast as 2.1, and a 10,000-page site uses 96% less memory per page view. I wrote up the full numbers in the Grav 2.2 release post, measured on real sites.

I won't pretend a well-tuned WordPress host is slow. It isn't. The difference is that Grav is fast by default, on cheap hosting, without you having to tune anything.

Security and Maintenance

WordPress core is solid these days. The trouble is the plugins. Patchstack's yearly reports put well over 90% of new WordPress vulnerabilities in plugins and themes, not in core. A typical WordPress site runs twenty or thirty plugins from as many different authors, and every one of them can read and write the database.

Grav has plugins too, and plugins can have bugs. But a few things work in your favor:

  • There's no database, so there's no SQL injection and no database password to leak.
  • A typical Grav site needs far fewer plugins, because things like Markdown, image resizing, caching, taxonomies, and multi-language support are built into core.
  • In Grav 2.0, any Twig code inside page content runs in a sandbox with an allowlist, so a content editor can't call into the system from a page.

Updates are a single command with GPM (bin/gpm update) or a button in the admin. Same as WordPress, really. You just have fewer things to update.

Editing Content

This is where WordPress has done a lot of work. The block editor (Gutenberg) is polished, it's visual, and non-technical editors are comfortable with it after an afternoon.

Grav's editing happens in Admin 2.0, the new admin that shipped with Grav 2.0. You get tree, list and column views of your pages, a Markdown editor with preview, and forms for every page setting. It's fast and it stays out of your way. Most people pick up Markdown in ten minutes, and some never want to go back.

But not everyone wants to see asterisks and pound signs, and that's what Editor Pro is for. It's a premium plugin that replaces the Markdown editor with a true WYSIWYM editor ("what you see is what you mean"). Your editors see headings, bold text, images, tables, and alerts formatted as they'll look, and they never touch Markdown syntax. Under the covers it still saves clean Markdown, so your files stay portable and Git-friendly. It also understands Grav shortcodes and other plugin content, showing them as visual blocks you can insert and configure from a form instead of typing them by hand. It isn't a page builder with drag and drop columns like Gutenberg. For someone who just wants to write and format content without learning Markdown, though, it's the answer, and it's what I'd hand to a client.

Grav also has two editing options WordPress doesn't really match:

  • Your own editor. Any text editor works, because pages are just files. I write most of my posts in a code editor and commit them with Git.
  • AI agents. Grav 2.0 ships with a first-party MCP server, so tools like Claude or ChatGPT can create and edit pages, manage media, and change settings through the same API the admin uses, with the same permissions as a user account. I manage several of my own sites this way now.

Themes and Plugins

No contest here. WordPress has tens of thousands of plugins and themes, and whatever you need, someone has built it. Probably five people have built it.

The Grav catalog is smaller: nearly 500 plugins and 129 themes on GPM. That covers forms, login and user accounts, SEO, sitemaps, comments, search, backups, and a lot more. But if your site depends on one particular WordPress plugin, check that Grav has an equivalent before you switch.

Themes work differently, too. A WordPress theme is PHP templates plus a lot of hooks. A Grav theme is Twig templates, which are much easier to read and safer to hand to a designer. And because Grav pages are files with their own templates, a theme in Grav tends to be built around the content it needs to display, rather than trying to fit every possible kind of site.

Ecommerce

WordPress has WooCommerce, which is free to start and powers a huge number of shops. It also turns into a stack of paid extensions once you need subscriptions, memberships, or more than the basic shipping and tax options.

Grav has KahunaCart, our native ecommerce plugin for Grav 2. It's $249 per site, once, and that covers the whole store: catalog, cart, checkout, orders, tax, shipping, digital downloads, and customer accounts. There are no transaction fees and no limits on products or orders. If you run a big catalog with thousands of SKUs and a warehouse integration, WooCommerce has the bigger ecosystem around it. For most small and medium shops, KahunaCart is simpler to run.

Cost and Hosting

Both are free and open source. WordPress is GPL licensed, Grav is MIT licensed.

WordPress needs PHP and a database, and you'll find a one-click installer on every host on the planet. Grav needs PHP 8.3 or newer and nothing else. You unzip it, point your browser at it, and create your admin account. It runs happily on the cheapest shared hosting, a $5 VPS, a Raspberry Pi, or your laptop.

The hidden cost with WordPress is usually the premium plugins and themes, plus the time spent keeping thirty of them updated. With Grav it's mostly your time learning a new system, which is a real cost too.

Headless and APIs

Both can run headless. WordPress has had a REST API in core since 4.7. Grav 2.0 ships a first-party API plugin that powers Admin 2.0 itself, so everything the admin can do, your frontend or your scripts can do too. If you want to build a React or Svelte frontend on top of a CMS, either one works. I'd argue Grav's is the cleaner of the two, because the admin depends on it and so it can't fall behind.

When WordPress Is the Better Pick

I'd pick WordPress for:

  • A large newsroom or multi-author publication with a heavy editorial workflow.
  • A site that depends on a specific WordPress plugin with no Grav equivalent.
  • A team where everyone already knows WordPress and nobody wants to learn something new.
  • A client who will hire a different agency next year, and needs a platform any freelancer can pick up.

When Grav Is the Better Pick

And I'd pick Grav for:

  • Marketing sites, product sites, and landing pages.
  • Documentation and knowledge bases, where Markdown and Git are a natural fit.
  • Personal blogs and portfolios.
  • Developers who want their content in version control and deployed like code.
  • Anyone tired of database backups, plugin update emails, and caching plugins.
  • Small and medium shops with KahunaCart.

At a Glance

WordPress Grav
Content storage MySQL / MariaDB database Markdown files in folders
License GPL MIT
Requirements PHP and a database PHP 8.3+ only
Editing Block editor Admin 2.0 with Markdown or Editor Pro, any text editor, AI via MCP
Caching Plugin or host Built in
Backups Plugin or host Copy the folder
Version control Hard (database) Natural (Git)
Templates PHP Twig
Plugins and themes Tens of thousands About 500 plugins, 129 themes
Ecommerce WooCommerce plus extensions KahunaCart
API REST API in core First-party API plugin

Moving From WordPress

There's no one-click WordPress importer for Grav today, and I'd rather be upfront about that. The usual route is to export your WordPress content as XML, convert the posts to Markdown with a converter script, and drop the resulting folders into user/pages/. For a small blog that's an afternoon. For a big site, an AI agent connected to the Grav MCP server can do a lot of the cleanup work for you, page by page.

If you get stuck, come and ask on Discord. Plenty of people there have made the same move.

Other Comparisons

If you're still weighing up your options, remote-job.net has a comparison of WordPress alternatives (in German) that covers Webflow, Ghost, Statamic, and others alongside Grav, with pricing and the limits of each one.

The next posts in this series put Grav next to Ghost, Statamic, and static site generators like Hugo. If there's a platform you'd like to see compared, tell me in the comments.

Quick Links

— Andy

Related posts

Keep reading