# Why MDX-in-Git beats a database for agent content

*By The Strand CMS Team · 2026-06-12 · 1 min read*

Canonical: https://www.strandcms.com/blog/why-mdx-in-git

> **Summary:** Git gives agent-written content a built-in audit log, review workflow, and rollback - and removes a whole class of database operations from the stack.

When an agent is the author, the most useful property of your content store is not query
flexibility - it is **traceability**. You want to see exactly what changed, review it,
and undo it. Git gives you all three for free.

## Every change is reviewable

An agent drafts a post, commits it to a branch, and opens a pull request. The diff is the
review surface. A human - or another agent - approves or requests changes. Merging is the
publish event.

## Rollback is a revert

A bad post is not a database migration; it is a `git revert`. History is never rewritten,
so the full record of what was published, and when, is always intact.

## No infrastructure to babysit

There is no database to provision, migrate, scale, or back up. The repository is the
backup. Deploys are static, so the indexed surface is fast and cheap by construction.

## The tradeoff, honestly

Files are not the right answer for highly relational, write-heavy applications. A
publication is the opposite: read-mostly, append-mostly, and happiest when its output is
static. That is exactly where MDX-in-Git wins.

## FAQ

**Doesn't a database scale better than files?**

For a publication's read-mostly content, static generation from files is faster and cheaper than a database, and the crawlable surface is fully static.

**How do agents edit content safely?**

Agents write MDX on a branch and open a pull request. CI validates the frontmatter; nothing merges to main directly.

## Sources

- [Strand CMS design notes](https://github.com/BowTiedSwan/strand)