Webstudio Content Engine: hundreds of pages without a database

We just moved the Webstudio blog off Ghost.

The articles now live as Markdown files in Webstudio. The Content Engine queries their fields, powers the article listings, and finds the right post for each URL. We no longer need an external CMS to run our own blog.

That is the reason we built the Content Engine. Most blogs, documentation sites, portfolios, and marketing sites need structured content, but they do not need a database and a separate service standing behind every page.

Webstudio can now handle that content directly. A project can have hundreds of pages backed by Markdown or JSON, with filtering, sorting, pagination, references between files, and dynamic pages selected by a URL slug.

Most content sites do not need a database

Take a blog with 300 articles. Its overview may need the title, excerpt, date, author, image, and slug from each published post. The article page needs one complete Markdown document matching the current URL.

Before the Content Engine, you had two common choices. Write the loading and query logic yourself, or put the articles into a CMS such as Ghost and connect it to Webstudio. Both work, and an external CMS is still the right choice for some projects. But neither should be mandatory for a folder of articles.

The Content Engine turns fields in Markdown frontmatter and JSON files into data that Webstudio can query. You can exclude drafts, filter by category or author, sort by publication date, paginate the result, and select one document by its slug.

Build those queries and bindings in the visual editor or through Webstudio MCP. Both work with the same project and produce the same website. The Content Engine documentation walks through the complete setup for an overview and a dynamic article page.

Simpler hosting was a deliberate choice

A database changes the operational shape of a website. It has to remain available, accept connections, survive migrations, and stay in sync with every deployment. A hosted CMS hides some of that work, but the site still depends on another service and its API.

Content Engine sites still have a backend. Webstudio stores the source files in R2 and serves them through a CDN. The difference is that you do not have to provision or operate a database just to publish structured content.

At build time, Webstudio compiles the fields needed for queries into a small content database. Complete Markdown bodies stay in R2 instead of being bundled into the website.

At runtime, a listing page queries the compact metadata. An article page uses the URL slug to select one document, then fetches only that Markdown body. A request for one post does not load the rest of the library, and the browser receives ordinary server-rendered HTML rather than a collection it has to sort with JavaScript.

Files keep the content portable

We chose Markdown and JSON because they remain useful without Webstudio. You can read them in a text editor, keep them in Git, generate them from another system, search them with command-line tools, or move them to another platform.

Images can use relative paths such as ./assets/content-engine.png. A post can refer to a shared author file instead of copying the same name, biography, and profile image into every article. Webstudio resolves and checks those references during the build, while the underlying content remains a set of ordinary files.

This also gives agents a practical way to work with a content collection. They can compare several articles, update frontmatter, repair links, or replace an image without making a separate API call for every field. The visual editor, MCP, and other tools can all work with the same source.

There is no proprietary content format to decode when you want to use those files somewhere else.

Limited in size, not in performance

This architecture has a capacity limit. The compiled metadata has to fit within the runtime, so the Content Engine is designed for hundreds of content pages rather than an unlimited archive.

That limit does not require every query to scan or download the entire collection. Listing queries run against compact metadata, and detail pages load only the selected bodies. Within the supported size, the architecture stays fast because the amount of content transferred for a request depends on the result, not the total number of Markdown files.

Some projects should still use a conventional CMS or database. Full-text search across a huge archive, complex permissions, transactions, highly relational data, or many editors changing content at once all bring requirements that a file-based engine is not trying to solve.

The majority of content sites are nowhere near that boundary. They should not have to start with the infrastructure required by the largest ones.

Our blog now runs on that assumption. You can inspect the result at webstudio.is/blog. To build your own, follow the Content Engine guide or start with the Markdown Blog template, which already includes the pages, queries, and bindings.