Why Bird CMS Has No Database on the Hot Path

Bird CMS stores content as markdown files on disk and never queries a database while serving a page. That one decision, no database on the hot path, is why it is small, fast, portable and hard to break. Here is the reasoning and the honest trade-offs.

What "no database on the hot path" means

When a visitor loads a page, the engine reads markdown files, parses them once, and caches the result in memory. There is no SQL query in the request. The database that most content systems put at the center of every page view simply is not there.

What you get for it

• git diff is your audit trail. Every edit is a commit. You can see who changed what and roll back with one command.
• cp -r is your backup. Content, uploads and config are the whole site. There is no dump and restore.
• grep is your search. Content is plain text on disk.
• Cheaper, simpler hosting. No database server to run, tune or patch. Any PHP host works.
• A smaller attack surface. No SQL injection surface, no database credentials to leak, no database to misconfigure.
• Portability. Move the folder and the site moves with it.

The trade-offs, honestly

• No relational queries at runtime. If your product needs ad-hoc joins across thousands of dynamic records, a database-backed app is the right tool.
• Search is text-based, not a query engine. The engine ships a substring search across files. For a very large catalog, add a dedicated search service.
• Scale is file-shaped. Files scale well for content, but a million dynamic rows belong in a database.

For content sites, docs, marketing pages and blogs, none of these bite, and the wins dominate.

How it stays fast

Markdown is parsed once and cached in memory, so repeat requests do not re-parse. The origami runtime serves the engine from a versioned, symlink-swapped release, so deploys and rollbacks are atomic. Measured server response is around 10 ms on a modest VPS, which you can see in the benchmarks.

Dynamic features still work

Lead capture, newsletter signup and event tracking are not gone. They write to disk or to a small local file off the hot path, or proxy to an external service. Page serving, the part that has to be fast for every visitor, stays database-free.

This is the same architecture behind every advantage in Bird CMS vs WordPress, and it is why the content model is just files.

Frequently asked questions

Does Bird CMS use any database at all?

The page-serving hot path uses none. Optional features such as analytics write to a small local SQLite file, but only when an event happens, never while rendering a page for a visitor.

Is a database not faster?

For dynamic, relational data, a database is the right tool and is faster. For serving content, reading a parsed file from memory is faster than running a query, because there is no query to run.

How do I search my content without a database?

The engine ships a search tool that scans the markdown files. It is fine for a typical content site. For a very large catalog, you would add an external search service.

Can I move my database-backed CMS to Bird CMS?

Yes. You export your content to markdown and drop it into content/. You lose the database, not your content.