Why I chose Astro over a heavy CMS

The question always arrives the same way: “why not just put this on a CMS and be done with it?” It is a fair question, and it deserves a technical answer rather than a preference.

What you are actually buying with a CMS

A CMS sells you three things: content editing without touching code, an ecosystem of modules, and an admin panel. Those are real advantages when you have dozens of editors, approval workflows and a catalogue that changes daily.

What the brochure leaves out is the cost: a database to maintain, a runtime to keep patched, plugins that get abandoned, and an attack surface that grows every month. You pay that cost even if your site is twelve pages and a blog.

What a static generator does instead

Astro compiles your content to HTML before the first visitor arrives. There is no database query per request, no process to restart, no PHP version to patch at midnight. The result is a directory of files that any server can hand out.

That changes the shape of the project entirely:

• Performance: the HTML is already built. There is nothing left to optimise afterwards.
• Security: with no database and no public admin panel, most attack vectors simply disappear.
• Cost: hosting static files is close to free.
• Portability: if you change providers tomorrow, you copy a folder.

When a CMS really is the right answer

This is not black and white. If you have a large editorial team, per-role permissions, content that changes several times a day, or a catalogue with thousands of products and live stock, then a CMS or a commerce platform does work that is not worth rebuilding.

The rule I apply is simple: choose the tool for the problem you have today, not the one you imagine having in three years.

The underlying point

The argument is not Astro versus CMS. It is understanding which problem you are solving before you pick the tool. If you cannot explain why you need a database, you do not need one yet.