Payload CMS vs Grav: when a marketing site needs a database, and when it doesn’t

Short answer: Payload is excellent. It is the best of the code-first headless CMSs, it is MIT-licensed, it installs inside a Next.js app, and we run it for clients who need it. But for most marketing sites it is more than they need. A Payload site is an application: a Node process, a Postgres or MongoDB database, file storage, an email provider and a CDN, each of which has to be hosted, patched, backed up and paid for. Grav is a flat-file CMS: pages are Markdown files in a git repository, there is no database, and since Grav 2.1 every page is also served as Markdown so AI agents can read it directly. For brochure sites, campaign sites, professional-services sites, documentation and most "we publish pages and posts" work, Grav does the job with less to run. Payload earns its place when there is real application behaviour: user accounts, relational data with real queries, one content API feeding a website and an app, workflow and roles at scale, commerce or dashboards, or a Next.js product that needs a CMS inside it. We build both, and we will tell you which on the first call.

What each one actually is

Payload describes itself as "the Next.js fullstack framework" and "the first-ever Next.js native CMS that can install directly in your existing /app folder" (Payload on GitHub). You write a config in TypeScript (collections, fields, access rules, hooks) and Payload generates the admin panel, the database layer and migrations, REST and GraphQL APIs, authentication and live preview (What is Payload). It runs on Postgres or MongoDB, with a SQLite adapter and a beta Cloudflare D1 adapter as well (SQLite adapter docs). The licence is MIT. In June 2025 the Payload team joined Figma, which said that "Payload will remain an open-source product" and that it would "continue to actively invest in and improve the open-source project" (Figma, Welcoming Payload). The stable line is 3.x (3.91.0 shipped on 15 October 2026) and a 4.0 beta is in progress (releases). The repository has over 45,000 stars. None of that is hype; it is a well-run project at the top of its category.

Grav is "a modern, open source flat-file CMS. No database, no SQL, no installation wizard" (getgrav.org). Every page is a folder containing a Markdown file with YAML settings at the top, plus its images. Grav 2.0 went stable on 20 June 2026 with "a real REST API at the heart of Grav," a rebuilt admin, "a first-party MCP server" so AI agents can do what an admin can do under the same permissions, and Twig in page content "sandboxed and off by default" (Grav 2.0 is stable). It runs on PHP 8.3 through 8.5. Grav 2.1 added the Markdown output we come back to below, and Grav 2.2 (24 September 2026) cut cold-start time in half and peak memory on a 10,000-page test site by 96 percent (Grav 2.2 released). Our flat-file builds add a block-based page system, a visual builder with inline editing and a deployment pipeline on top of it.

The difference that matters to a buyer is not features. It is that a Payload site has an application layer and a database, and a Grav site has files. Everything else in this post follows from that.

The question: does the database earn its keep?

A database is not a cost in itself. It is a cost you accept to get three things: queries across many records, concurrent writes from many users or systems, and data that other applications need to read and write through an API. A marketing site with 40 pages and a blog needs none of those. A member portal with 5,000 accounts, gated downloads and a mobile app needs all three.

That is the whole decision. The rest of this post is detail on what each side costs and buys.

What you take on with Payload

Payload's own deployment guide says most projects "will also need a database, file storage, an email provider, and a CDN," and warns that on hosts with an ephemeral filesystem (it names Heroku and DigitalOcean Apps) uploads are lost on restart, so you add a storage adapter for S3, Azure, Google Cloud, Uploadthing or Vercel Blob (deployment docs). Payload Cloud, the first-party host, paused new project deployments after the Figma acquisition, so for a new project you self-host (dev.to cost breakdown, updated October 2026).

Reasonable running costs, from published sources rather than our quotes:

• Vercel plus a managed Postgres. Vercel's Hobby plan is "for personal, non-commercial use," so a client site starts on Pro at $20 per developer seat per month (Vercel pricing). Neon's free tier gives 1 GB of storage and 100 compute-hours per project, with scale-to-zero after five minutes; the Launch plan is usage-based with no minimum (Neon pricing). One developer who ran several Payload sites this way reports a trap worth knowing: a scheduled job that polls every few minutes keeps waking the database, and he "consistently landed at $30–$50 per month" for sites with almost no traffic (Build with Matija). The dev.to breakdown puts a small production site at $30–45 a month in infrastructure, before anyone's time.
• A VPS with Docker. The same author estimates that "a small production site on a Hetzner VPS with a self-hosted Postgres instance can run under EUR 10/month," and that mid-scale managed hosting with a managed database "typically runs $40–$100/month" (Payload CMS pricing guide). The cheap VPS figure is real, but it assumes someone is comfortable owning a Postgres instance: upgrades, backups, restore tests, disk.

Then there is the build. Payload has no themes. The front end is a Next.js application you write, and every content type is a React component you maintain. AI coding tools have made this far cheaper than it was (Payload publishes official agent skills, and we covered the effect on build cost in our headless WordPress post), but it is still an application with a dependency tree, a build step and a Node runtime that will need upgrading. Someone has to own it for the life of the site.

What you get for all that is genuinely good: a typed content API, drafts, autosave, version history with diffs and restore, scheduled publishing (versions docs), live preview of your real front end inside the admin (live preview docs), and authentication on any collection with auth: true, meant for "e-commerce customer accounts, SaaS users" and the like, not just admins (auth docs). If your site needs those things, nothing in the flat-file world matches them.

What you take on with Grav

A Grav site is a folder. PHP serves it; there is no second process and no database. Hosting is a small VPS or a static-class PHP host. DigitalOcean's smallest Droplet is $4 a month (DigitalOcean pricing), and it is more than a brochure site needs; we run client sites on a shared hardened server with daily backups, and the hosting line on the invoice is a fraction of a Payload stack.

Backup is copying a folder. Rollback is git revert. A content change is a diff someone can read in a pull request. Updates are a git pull on the core and plugins, which is the same operation as deploying content.

Security is where the architecture does the most work. OWASP's Top 10 still ranks injection third, and found that "94% of the applications were tested for some form of injection" (OWASP Top 10: Injection). A site with no SQL layer has no SQL injection class to defend, no database credentials to leak and no database port to expose. The remaining surface is PHP, the web server and the admin login, which is the same list every PHP application has, with less behind it. Grav 2 also removed its own worst habit: Twig inside page content is now sandboxed and off by default.

Editors do not touch files. On our builds they open the page, click a heading and type, drag sections into a new order, swap an image or add a section from the block library. Content is still saved as Markdown in git underneath, which is what makes it portable: if a client leaves Grav later, the content is already in the most portable format there is.

Where flat-file breaks down

We will say this plainly because vendors on the database side say it loudly. Flat-file systems have no query engine; a Kirby forum thread on when that CMS is the wrong fit gets the same answer we would give, that file-based systems struggle once "a lot of data is stored and called" and that query functions "usually have to be written from scratch" (Kirby forum). Strapi's guide to flat-file CMSs, which has an obvious interest but is not wrong, says they "struggle with scalability, team collaboration, and dynamic features as projects grow" (Strapi).

Concretely, Grav is the wrong tool when:

• You have tens of thousands of records and need to filter and sort across them on every request. Grav 2.2's lazy page index handles sites past 1,000 pages comfortably, and the 10,000-page test site served pages at under 20 ms warm, but "find all products under $50 in this category sorted by rating" is a database query, not a page tree.
• Many people write at the same time to the same content. Files and git handle a handful of editors; they do not handle fifty.
• Content has many-to-many relationships that must stay consistent when either side changes.
• Other applications need to write content, not just read it.

If any of those describe your site, the database is earning its keep and you should read the Payload column of the table below as the recommendation.

The AI and agent angle

This is new enough that it deserves its own section, because the two platforms arrive at agent-readability from opposite directions.

Grav 2.1 made it native. Append .md to any page URL, or send Accept: text/markdown, and the page comes back as Markdown rather than HTML: the main content region only, with a YAML header and links to the parent, neighbouring and child pages so an agent can move through the site without leaving Markdown (Grav 2.1.0 release notes). The sitemap plugin generates an llms.txt that indexes those Markdown URLs (AlternativeTo). The first-party MCP server lets an agent read and, with permission, edit content through the same API and permissions as the admin. Try it on this site: /services/flat-file-sites.md.

Payload is excellent for agents that build and manage content. The official @payloadcms/plugin-mcp exposes find, create, update and delete tools for every collection and global, filtered by Payload's access control, over HTTP at /api/mcp (MCP plugin docs), and the newer LLM Instructions feature lets you attach Markdown guidance to a collection so an agent knows how to write for it (LLM instructions docs). Those are the right tools for an agent operating a content pipeline. What Payload does not do out of the box is serve your public pages as Markdown to the assistants your customers are using. Content lives in Lexical rich-text JSON; there is a convertLexicalToMarkdown helper (docs), but turning a page built from blocks into a clean Markdown document at a public URL is a custom endpoint you write and maintain. We do it as part of our AI integration work, and it is a day's work, not a week's, but it is work.

Neither of these is a reason on its own to pick a platform. It is a reason to notice that the flat-file site gets the public-facing half for free.

The decision table

Signs you actually need Payload

• People log in to the public site: members, customers, students, partners.
• Content has to feed more than a website: a mobile app, a kiosk, a partner feed, a second site with different templates.
• You have relational data with real queries: a product catalogue with filters, a directory with facets, a course library with prerequisites.
• Many editors, with roles, approvals, scheduled publishing and field-level permissions.
• The site is a product: dashboards, calculators that save state, commerce, anything that writes data from the public side.
• You already have a Next.js application and want the CMS inside it rather than beside it.
• Other systems need to write content into the site, not just read it.

Two or more of those, and the database is earning its keep.

Signs Grav is enough

• The site is pages, posts, a few forms and some embeds (HubSpot, Marketo, Calendly, a video player).
• Fewer than a few hundred pages, and no page needs to query across the others.
• One to five people edit it, and none of them need an approval chain.
• Nobody logs in except editors.
• Leadership cares about speed, security and whether AI assistants can read the site, and would rather not pay for a database to get there.
• You want content in git, reviewed like code, and portable if you ever move.
• There is no developer on staff to own a Node application, and you do not want to hire one for a brochure site.

Most of those, and you are the site we build on Grav. The build is faster, the hosting is cheaper and the site has fewer ways to break.

Two worked examples

A B2B services firm: 40 pages and a blog. A regional engineering consultancy with eight service pages, a dozen case studies, team and careers pages, a blog that gets two posts a month and a contact form that feeds HubSpot. Two people in marketing edit it. Nobody logs in from outside. The content model is pages, posts and a handful of reusable sections (a proof strip, a CTA, a client logo wall). We would build this on Grav: block-based pages in the visual builder, global sections for the repeated bits, the HubSpot form embedded, every page served as Markdown and listed in llms.txt for the assistants their prospects are asking. Hosting is one line on a shared hardened server with daily backups. The care plan is light because there is no database to patch and no Node app to upgrade. A Payload build would produce a site that looks the same and costs more every month for a query engine nobody uses.

A member portal: gated resources and a mobile app. A professional association with 6,000 members, a library of 1,400 gated documents tagged by topic, region and membership tier, a public events listing that members can register for, and an iOS app that shows the same library and events. Members log in, search and filter the library, and download. Staff in four departments publish, with an approval step before anything goes live. This is Payload without a second thought: a members collection with auth: true, a resources collection related to topics, regions and tiers with access rules that check the member's tier, an events collection with registration, drafts and roles for the four departments, and one typed API that the Next.js site and the app both read. Grav would need a database bolted on to do any of it, at which point you have the costs of both and the strengths of neither.

Most real briefs sit closer to the first example than they admit. The question we ask is which parts of the second example you actually have, in writing, today, rather than might want in three years. A Grav site's content is Markdown in git; if the portal arrives, it migrates into Payload cleanly, and you will have spent three years not paying for it.

What to do next

We build and host both platforms, so the recommendation is based on your site, not on what we would rather build. Send us the brief, the current site or the list of things it has to do, and we will tell you on the first call whether the database earns its keep, and why. Book a call.