Does a Marketing Site Need a Real Database?

Does a Marketing Site Need a Real Database?

Most do, and most do not have one. They have a CMS, which is a database wearing an editing interface, or they have content pasted into page files. A real database is worth it the moment content becomes something you query, report on and generate pages from rather than something you type.

This is a behind-the-studio piece. We run our own site this way, and the decision was not obvious at the time, so it is worth explaining what we actually gained and what it cost.

The short version: the database is not there to make the site work. It is there to make everything around the site work.

What Do Most Marketing Sites Use Today?

A CMS, overwhelmingly. W3Techs, in its survey dated 20 September 2026, reports that WordPress is used by 40.2 percent of all websites it monitors, giving it a 58.8 percent share among sites that use a CMS at all, with Shopify at 5.4 percent, Wix at 4.2 percent and Squarespace at 2.4 percent of all sites.

The HTTP Archive Web Almanac for 2025, published in January 2026, puts the same picture from the other side: CMS-driven sites account for over 54 percent of observed websites, and WordPress powers roughly 64 percent of those.

So the default answer is already a database. What varies is whether anyone treats it like one, or whether it is simply the thing the editor saves into.

Why Does That Distinction Matter?

Because it decides what you can do with your content besides show it. A CMS optimised for editing stores content shaped for pages. A database designed for the content itself stores facts, and pages are one of the things you can build from them.

The test we use is simple. Can you answer "how many articles did we publish in each category last month" with a query, or does someone have to count them in an admin list? If it is the second, your content is in a filing cabinet, not a database.

That sounds academic until you want to automate something. Every reporting task, every audit, every bulk fix and every integration is trivial against a real schema and miserable against a page tree.

What Does Our Own Setup Look Like?

Content lives in a Postgres database. The site is prerendered at build time, so the build reads published rows and writes a static HTML page for each one. The browser never talks to the database. Visitors get flat files from a CDN.

The result is a site with the delivery characteristics of a static site and the content characteristics of an application. Nothing is computed at request time, so there is no server to be slow, and nothing is hardcoded, so there is no file to hand-edit when a category changes.

The cost is a build step. A published row is not live until a build runs. That is a real constraint and we accepted it knowingly, because for a marketing site the content changes on a publishing schedule, not per visitor.

What Did That Actually Buy Us?

Automation we could not have built otherwise. Because the content is queryable, the publishing pipeline can check what exists before writing something new, count what has been published by category, and refuse to create a duplicate slug at the database level rather than by convention.

It also made the site's own reporting honest. Instead of trusting an admin list, we can compare the count of published rows against what is in the sitemap and against what is actually on the live site. When those three numbers disagree, something is broken, and we find out on a schedule rather than by accident.

None of that is exciting. All of it is the difference between a blog you maintain and a blog that maintains itself.

Is This Just a Headless CMS With Extra Steps?

It overlaps a lot, and for most teams a headless CMS is the right version of this idea. You get the API, the content model and an editing interface someone non-technical can use, without owning a database.

We went the other way because our content pipeline is largely automated, so the editing interface was the least important part and the ability to write SQL against it was the most important. That is an unusual trade and we would not recommend it by default.

If you are weighing the options, our piece on headless CMS explained lays out where each approach fits. The question is not which is more modern. It is who edits, how often, and what else touches the content.

Does a Database Make a Site Faster?

Not by itself. What makes a site fast is not rendering at request time and not shipping unnecessary weight, and you can get both wrong on any stack.

The Web Almanac's 2025 numbers show how wide the spread is between platforms. On mobile, median page weight ran to 3,974 KB for Squarespace, 2,900 KB for Joomla and 2,894 KB for WordPress. Its Core Web Vitals pass rates on mobile ranged from 85 percent of Duda sites and 79 percent of TYPO3 sites achieving a good score, down to 45 percent for WordPress.

Those gaps are not caused by where the content is stored. They are caused by what each platform puts on the page. A database gives you control over the pipeline, and what you do with that control is still the whole game.

When Is a Database Genuinely Overkill?

When the site is twelve pages that change twice a year. A brochure site with no blog, no case studies and no programmatic pages does not need a content layer, and adding one buys you a build pipeline to maintain in exchange for nothing.

It is also overkill when nobody on the team can query it. A database whose only interface is an engineer's laptop is worse than a CMS, because the marketing team's velocity now depends on someone else's calendar.

The honest threshold is roughly this: when you have more than about fifty content items, more than one content type, and at least one thing you want to generate rather than write, a real content layer starts paying for itself.

What Should You Get Right First?

The content model, before anything else. Fields you regret are expensive to change once a few hundred rows exist, and the mistakes are predictable: one field doing two jobs, a category stored as free text, and dates stored without timezones.

Our own schema is deliberately boring. Slug, title, category, excerpt, body, read time, author, a couple of SEO fields, a published flag and a published timestamp. Nothing clever, and every field has exactly one job.

If you are designing one now, our piece on content modelling for a CMS covers the decisions that are hard to reverse. Spend the time there, not on the rendering layer.

So Should You Build One?

Only if content is a system for you rather than a task. If your marketing site is a set of pages someone updates occasionally, use the CMS your team already knows and spend the saved effort on the pages themselves.

If you are running a content engine, generating pages from data, or trying to automate any part of publishing, then the content needs to live somewhere you can query, and that decision comes before the choice of front end. Get that right and the rest of the stack becomes replaceable, which is the actual goal.

If you want to talk through what your content layer should look like before you commit to a platform, we are happy to walk through it. You can reach our team at phoenix.studio.