The case for static: why your marketing site might not need a database

01What "static" actually means now

"Static" still drags 1998 behind it: hand-edited HTML, broken image icons, a webmaster email in the footer. That's not what anyone means by it anymore. A modern static site is generated. The content lives in plain files (Markdown, JSON, whatever fits the material), a build tool pours those files through templates, and the output is finished HTML, ready to serve. The build tool I use is Eleventy, and the wider approach goes by the name JAMstack.

The part that matters is when the work happens. On a WordPress site, each page is assembled while your visitor waits: PHP runs, a database answers queries, the pieces get stitched together, then the page ships. On a static site, every page was built before anyone asked for it. The build runs on my machine or a CI server whenever the content changes, and what sits on the host is a folder of plain files. Nothing is left to compute at request time, which means there's very little left to break at request time.

Database-backedRuns every visit

1. A visitor asks for the page
2. PHP starts up
3. The database answers its queries
4. The pieces get stitched together
5. The page ships, and the visitor stops waiting

StaticRuns once per change

1. The build runs, on my machine or a CI server
2. Templates pour the content files through
3. Finished HTML lands in a folder

Then every visit is one step: a CDN hands over the file.

02The maintenance you stop doing

Run a WordPress marketing site for a year and you learn its rhythm: core updates, plugin updates, the plugin that breaks another plugin after an update, the PHP version bump your host emails about, the database that needs backups, and a security plugin watching the login page for brute-force attempts. None of it is hard, and all of it is recurring, so someone has to do it or pay for it.

Here's the equivalent list on the static side: almost nothing. There is no database to host, back up, or breach. There's no server-side runtime to patch, because nothing runs on the server; it just hands out files. Hosting is cheap or free (GitHub Pages and Netlify both serve sites like this for nothing at small-business scale). And most of the attack surface simply isn't there. You can't SQL-inject a folder of HTML, and there is no admin login to brute-force.

Recurring job	WordPress	Static
Core and plugin updates	WordPressOngoing	StaticNone to install
Plugins breaking each other	WordPressWhenever they collide	StaticNo plugins
PHP version bumps	WordPressWhen the host emails	StaticNothing runs on the server
Database backups	WordPressOngoing	StaticNo database
Watching the login page	WordPressOngoing	StaticNo admin login to watch

Both columns describe a small marketing site, the size this note is about

You also get version control as a side effect. The content is files, so every change has an author, a date, and an undo. "Who changed the pricing page in March" stops being a mystery and becomes a one-line command.

03Fast by default

A static page skips the two slowest steps of serving a page, the database queries and the per-request rendering, because both already happened at build time. What's left is a CDN handing a file to a browser, usually from a machine physically near the visitor. That's about as fast as the web gets.

Google measures this. Core Web Vitals feed into how pages rank, and prebuilt pages tend to clear those thresholds by doing less, not by optimizing harder. To be fair: static is not automatically fast. You can still bury a prebuilt page under three megabytes of JavaScript. But the defaults are on your side, and losing the speed takes active effort.

04What I have shipped

I run my own sites on Eleventy, at opposite ends of the size range.

SongSuey is a music credits site: 425+ artists, 3,800+ albums, and 48,000+ hand-verified track credits, every one of them served as a static page. Eleventy 3 builds the whole thing from JSON data files, GitHub Actions runs the build, and GitHub Pages serves it for free.

PureCSS.com goes a step further: it publishes itself. A daily cron job rebuilds and redeploys the site with nobody at the desk. It was set up once, and it has been quietly shipping ever since.

At a previous job I built the site for Soarveyor, a drone-inspection company: an Eleventy build served from a CDN, images handled by Cloudinary, and a git-based CMS layered on top so the team could edit content without ever seeing a line of code, a normal company site with non-technical editors on the JAMstack.

05When static is the wrong tool

I build database-backed sites too, and here is where static loses:

• Frequent, non-technical editors. If five people publish every day and none of them will touch git, WordPress's editing experience is good enough to be worth its upkeep. A static site can get a CMS layer, like Soarveyor's, but that's a workflow you set up and teach, not something you get for free.
• Ecommerce. Carts, inventory, checkout, customer accounts: that's an application, not a brochure. Use Shopify or something like it, and spend your energy making that fast.
• Logged-in anything. User accounts, dashboards, saved state. Third-party services can bolt some of this onto a static front end, but past a certain point you're building an app and should just build an app.
• Very large sites. Build times grow with page count. SongSuey's few thousand pages build comfortably; a few hundred thousand pages belong on a different architecture.

Hybrids cover a lot of the middle ground: a static marketing site in front of a Shopify checkout, or a headless CMS feeding the build so editors get a friendly interface while visitors still get flat files.

06What a migration looks like

If you're on WordPress and this sounds appealing, the move is less dramatic than it sounds. The shape of it: export the content, rebuild the templates (usually an upgrade, since old themes accumulate cruft), map every old URL to its new home with redirects so your Google rankings survive the switch, then point DNS once everything checks out. Your visitors shouldn't notice anything except that the site got faster.

1. Step 01

   Export the content

   Out of the database and into plain files.

2. Step 02

   Rebuild the templates

   Usually an upgrade, since old themes accumulate cruft.

3. Step 03

   Map every old URL

   Redirect each one to its new home, so your rankings survive the switch. This is the step to be fussy about.

4. Step 04

   Point DNS

   Last, and only once everything else checks out.

The one decision to make early is the editing workflow, because going static makes you choose one on purpose: git if your editors are technical, a CMS layer if they aren't, or structured data files if the content really lives somewhere else anyway, the way SongSuey's credits live in JSON. Pick it before the build starts, not after.

07The short version

For a lot of small businesses around Chicago, the marketing site is five to fifteen pages plus a blog that gets a post a month. That is exactly the site static was made for, and hosting it costs close to nothing.

If that sounds like your site, look over what I offer or get in touch and tell me what you're running today. If you need an Eleventy developer, that's me. If WordPress or a full application fits your situation better, I'll point you that way instead.

FN-08 · End of sheet