Choosing between a database CMS, Git CMS and no CMS

For years, I have been asked some variation of the same question: Which CMS should I use?

WordPress is usually part of that conversation. Sometimes Drupal, a headless CMS, a Git-backed CMS, or whichever platform is receiving attention at the time.

After building and maintaining websites for many years, I increasingly think that starts in the wrong place. The first question is not which CMS the client needs. It is:

What does the client actually want to create, manage and change?

A news publisher producing several articles each day has different requirements from a small company that changes its service pages twice a year. An online booking platform with live availability has different requirements again. Starting all three projects by selecting a CMS makes little sense.

For many websites I build today, editorial content can live directly in Git. It is versioned, reviewed and deployed with the website. If the client needs a visual interface, I can put a Git-driven CMS in front of those files. If nobody needs that interface, I often prefer not having a CMS at all.

At the other end of the scale, a database-driven CMS is unquestionably the right solution when a project has many editors, complex relationships, accounts, inventory, bookings or constantly changing information.

The useful decision is therefore not which platform I prefer. It is which architecture is the simplest one that fits the real content and business workflow.

Database CMS vs Git CMS vs no CMS

This is the short comparison.

	Database-driven CMS	Git-driven CMS	Git, no CMS
Canonical editorial content	Database	Files in a Git repository	Files in a Git repository
Typical examples	WordPress, Drupal, EmDash	TinaCMS, Decap CMS	Astro with Markdown or MDX
Visual editor	Yes	Yes	No dedicated CMS interface
Revision history	CMS and database	Git	Git
CMS maintenance	Yes	Yes	No CMS to maintain
Content database backup	Required	Files remain in Git; supporting services may still need backup	No content database
Relational or transactional data	Strong	Limited	Limited
Static public delivery	Possible	Natural	Natural
Editorial permissions	Usually mature	Product and workflow dependent	Repository and review workflow
Public CMS attack surface	Usually broader	Can be separated from the public site	None, although the site can still have other dynamic services
AI-assisted repository workflow	Possible	Strong	Very direct

None of the columns is automatically the winner. A database CMS can be the best possible choice for one company and unnecessary lifetime cost for another.

Start with the workflow, not the platform

Before choosing technology, I want answers to a few concrete questions:

• What exactly will be edited: pages, articles, products, prices, availability, accounts or transactions?
• Who will make the changes, and are they comfortable working with a developer?
• How often does the information change?
• Does it need to change immediately, or is a reviewed deployment acceptable?
• Are there several editors, approval stages, scheduled publishing or detailed permissions?
• Is the information editorial, relational or transactional?
• Does the same content need to feed several websites, apps or channels?
• Who will maintain the platform, backups, permissions and deployment workflow after launch?

These answers matter more than whether a CMS is described as traditional, headless, composable or modern.

This guide also sits beside, rather than replaces, the broader explanation of web development stacks. A CMS is one architectural component. Hosting, application code, databases, APIs, caching and deployment still need their own decisions.

Database-driven CMS

What I mean by a database-driven CMS

A database-driven CMS stores editorial content and configuration in a persistent database.

WordPress is the familiar example. A normal installation runs on PHP with MySQL or MariaDB, as described in the current WordPress requirements. Drupal follows the same general model and currently supports MariaDB, MySQL, PostgreSQL and SQLite with version-specific requirements documented by Drupal.

Newer software can use the same architectural idea. EmDash is an Astro-native TypeScript CMS that stores content in SQLite, libSQL, Cloudflare D1 or PostgreSQL and media in S3-compatible storage. It looks very different from WordPress, but its canonical content still lives in a persistent data layer rather than Git-backed Markdown files.

Keeping WordPress as the editor while moving the public frontend elsewhere is another variation. That narrower decision is covered in the headless WordPress guide.

Database-driven does not mean old, and Git-driven does not automatically mean modern. They solve different problems.

PHP does not require a database

PHP often appears in this discussion because WordPress and Drupal are written in PHP. PHP itself does not require a database. A PHP website can read files, call APIs or render templates without connecting to MySQL. The same is true for JavaScript, TypeScript, Python, Ruby, Java and C#.

The database exists because a CMS or application needs to persist pages, users, permissions, revisions, relationships, settings and operational state.

Browser
   ↓
Web server
   ↓
PHP / Node / Python / etc.
   ↓
CMS or application
   ↓
Database

The server-side language is not the reason for the database. Persistent, dynamic data is.

That distinction prevents false choices. A mostly static website can have a server-side booking API. A PHP site can have no database. An Astro site can use a database. The architecture should follow the data, not the language label.

Where I would choose WordPress or Drupal

If a client has a genuine editorial organisation, the CMS is doing real work.

Imagine a publisher or larger organisation where several people create content, another person approves it, someone manages users, articles are scheduled, and editors must search thousands of entries. Mature platforms have spent years solving those editorial problems.

It is possible to recreate parts of that workflow with GitHub, pull requests and custom tooling. At some point, however, that becomes an attempt to rebuild a CMS. I would rather use a mature CMS when its workflow is a genuine requirement.

The same applies when non-technical editors frequently need page building, media libraries, granular roles, previews, taxonomies or plugin-driven workflows. Familiar editing can be worth the operational cost.

Where a database is the right tool

The case becomes stronger when the information itself is dynamic.

Products can have variants, prices, stock levels, categories and customer-specific rules. A query such as “show all available blue chairs below this price” is exactly the kind of work a database is designed to handle.

Bookings make the distinction even clearer. Availability changes, reservations are created and cancelled, rates vary by date, customers log in and payments happen. I would not store that information in Markdown simply because Git is convenient.

For a property website, a description may work perfectly in MDX. Its availability calendar almost certainly belongs in a booking system, API or database. The guide to reliable API integrations explains the operational side in more detail, and the klik.villas case shows why booking data and editorial pages need different responsibilities.

One of the most important rules in this discussion is:

Editorial content and application data are not necessarily the same thing.

The lifetime cost of a database CMS

A database CMS becomes questionable when substantial infrastructure exists for a site that hardly changes.

A ten-page company website may have a PHP runtime, database, CMS login, plugins, backups, scheduled tasks and caching layers. Then somebody logs in twice a year.

There is nothing inherently wrong with that setup. The question is whether every moving part earns its place.

The CMS, extensions and server runtime need updates. The database and uploads need backups. Compatibility needs checking. Major versions eventually require migration. Security and account access need continued ownership.

The real cost of a CMS is not only its licence or monthly hosting price. It is its lifetime operational cost.

Revisions, backups and security

Revisions demonstrate the difference between database and Git-based content. WordPress deliberately stores revisions so editors can compare and restore earlier versions. That is useful functionality, and revisions do not automatically make WordPress slow.

They do show how the database becomes more than the published page. It can contain current and previous content, metadata, users, configuration, plugin settings and other operational records. That asset needs maintenance and reliable backup.

A traditional CMS backup may need the database, uploaded media, custom code, configuration and extensions to remain consistent. Restoring yesterday’s database with last week’s media can produce a technically restored but inconsistent website.

Security follows the same principle. A CMS may expose login, administration, APIs, uploads and server-side code. Plugins add more code. WordPress maintains detailed hardening guidance because useful software still needs to be secured.

That does not make WordPress inherently insecure. It means software that provides value also creates maintenance work and attack surface.

Git-driven CMS

What Git-driven means

A Git-driven CMS provides an editorial interface while keeping files in Git as the source of truth.

TinaCMS describes itself as a Git-backed headless CMS with content in Markdown, MDX and JSON. It adds an editor and content API; its data layer uses a database as an index or cache, but the files remain canonical.

Decap CMS also puts a friendly editor in front of a Git provider. Its editorial workflow can translate drafts and publishing actions into branches, commits and pull requests. It supports providers including GitHub, GitLab and Bitbucket.

The workflow becomes something like:

Editor
   ↓
TinaCMS / Decap CMS
   ↓
Markdown / MDX / JSON
   ↓
Git repository
   ↓
Build
   ↓
Website

This is often my preferred compromise when the client genuinely needs an editor but the public site does not need a content database at runtime.

Why Git works well as the source of truth

The biggest benefit is not that Markdown is fashionable. It is that the repository becomes a more complete representation of the website.

Cloning the project can provide code and content together. Content changes can use the same review, preview and deployment workflow as code. A broken change can be associated with a commit and reverted. The current file stays simple while earlier versions live in Git history.

That makes editorial files portable. They are not trapped behind a proprietary export format or dependent on a production database just to run the site locally.

TinaCMS and Decap CMS in practice

TinaCMS gives editors an interface over file-based content. They do not need to understand MDX frontmatter to change an approved field. Tina can keep media in the repository or connect to external storage, which is useful because media volume often determines whether a pure repository workflow remains comfortable.

Decap CMS takes a direct Git workflow approach. Authentication and permissions still need careful design. With a GitHub backend, normal editors need the relevant access, while open authoring can use forks and pull requests for contributors without direct write access.

This reveals the main tradeoff: the editor may look simple, but Git permissions, preview deployments and publishing rules still exist underneath. Somebody must configure and own them.

When a Git CMS fits

It is strong when most information is editorial rather than transactional:

• Service pages
• Articles and guides
• Case studies
• Staff profiles
• FAQs and documentation
• Destination content
• Stable property or product descriptions

The client gets visual editing. The developer gets version-controlled, portable files close to the code.

After publication, a build can generate static HTML and serve it from a hosting platform or CDN. The CMS does not need to answer every public page request. If the editor is temporarily unavailable, the already deployed site can continue to work.

Where a Git CMS becomes the wrong tool

A Git CMS is still another system. It needs configuration, authentication, repository permissions, preview behavior, media decisions and reliable builds. Its own dependencies and integrations also need updates.

Git is not a database replacement. It is a poor choice for live inventory, transactions, customer sessions or frequently changing availability. A few hundred or many thousands of editorial files can be manageable, but transaction volume and relational queries are different problems.

The goal is not to put everything in Git. It is to put the right information in Git.

No CMS, but still a controlled workflow

What no CMS actually means

No CMS does not mean uploading loose HTML over FTP. It does not mean no version control, no structure and no review.

I still want a Git repository, branches, commit history, automated builds, previews, schemas and validation where appropriate. The difference is simply that there is no separate CMS interface.

An Astro project might contain:

content/
├── articles/
├── cases/
├── services/
├── team/
└── guides/

The content can be Markdown or MDX with structured frontmatter. The build can validate required fields and stop a deployment when the content model is invalid.

That is controlled content management. It just is not a CMS product.

Why I increasingly like this option

Many smaller business websites need a CMS more during the sales conversation than after launch.

A company says it must be able to edit everything. Two years later, the CMS has been opened three times. When a real change is needed, the owner emails the developer because it involves layout, related pages, SEO metadata, redirects or an integration.

In that situation, I would rather start with the simpler architecture. No CMS means one less application, authentication system and administration interface. It can also mean no public content database.

For a small service business that changes a few pages every month or quarter, a controlled development workflow may be better suited than paying the operational cost of a rarely used CMS.

The repository becomes the content workflow

Without a CMS, a content change is a normal repository change. Related edits can belong to one commit. A reviewer can inspect the diff. A branch can create a preview. Validation can run before merge. A bad change can be reverted.

What disappears is the abstraction layer designed for editors. If nobody needs that interface, it is difficult to justify maintaining it.

AI changes the interface, not the responsibility

Historically, no CMS had an obvious problem: developers were comfortable editing Markdown, but most clients were not. Explaining frontmatter, commits and pull requests was not a realistic substitute for a good visual editor.

Repository-aware AI tools change that interface. A client or developer can request: “Change the delivery time from five to seven working days everywhere, but do not alter old case studies.” An agent can search the repository, identify the relevant files, make a consistent change, run validation and prepare a pull request.

The requester does not need to know where every file lives. In that sense, an AI-assisted workflow can provide part of the interface that previously required a CMS.

This does not make CMS platforms obsolete, and it should not mean unrestricted publishing. I prefer a reviewable workflow:

Requested change
      ↓
AI updates files
      ↓
Build and validation
      ↓
Pull request and preview
      ↓
Human review
      ↓
Merge and deployment

The responsibility remains human. The tool reduces the technical friction around preparing a change.

Security and backup without a CMS

A statically generated public site may have no CMS login, content database or general-purpose application processing an article request. The visitor receives HTML, CSS, JavaScript and images. That removes CMS-specific attack surface from the public site.

It does not remove security concerns. Repository accounts need strong authentication. Access must be limited. CI/CD credentials need protection. Dependencies and third-party actions need review. Forms, APIs and booking flows still require their own security.

The attack surface changes and can become smaller, but it never becomes zero.

Recovery is often simpler for files stored in the repository because code and content share revision history. GitHub documents mirror clones and other repository backup options. I would still keep a separate backup for an important repository.

External media needs its own plan. Images in R2, S3 or an image service are not backed up merely because the content files live in Git.

You do not have to choose only one

Most real websites are already hybrid. The useful question is where each type of information belongs.

Consider a property rental site:

Property descriptions → Git repository
Destination guides    → Git repository
Articles and FAQs     → Git repository
Availability          → Booking API
Rates                 → Booking API
Reservations          → Database
Images                → Object storage

Editorial descriptions may change a few times per year. Availability can change every minute. Rates depend on dates, seasons and stay length. Reservations need to be recorded immediately.

Trying to force all of that through one CMS creates the wrong coupling. A database-backed booking system can handle application data while a static public site uses Git-based content. A contact form can run as a serverless function. Search can use a focused index. Authentication can belong to a separate service.

The fact that one feature needs a database does not mean the About page must live there. Likewise, the fact that service pages work well in Git does not mean a booking belongs in Markdown.

Instead of asking which CMS should own the website, ask which system should be the source of truth for each kind of information.

A decision guide

Choose a database-driven CMS when:

• Many editors need mature roles, scheduling, approval and search
• Content has complex relationships or must update immediately
• Products, accounts, transactions or bookings are central
• A familiar administration interface is used frequently
• The organisation can own updates, backups and security

Choose a Git-driven CMS when:

• Content is mainly editorial and file-shaped
• Editors need a visual interface
• Version control, previews and portable content matter
• The public site benefits from static delivery
• The team can own Git permissions, builds and CMS integration

Choose Git without a CMS when:

• The site is relatively stable
• A developer or controlled AI-assisted workflow maintains content
• Review and deployment can happen through pull requests
• Removing an unused admin system reduces lifetime cost
• There is still a clear owner for content changes and backups

Choose a hybrid architecture when editorial content and live application data have different needs. This is often the most honest answer.

Frequently Asked Questions

Does every business website need a CMS?

No. A CMS is valuable when people regularly use its editor, permissions, publishing workflow or content model. A relatively stable company website can be easier to maintain with structured files in Git, reviewable changes and automated deployment.

Is WordPress a bad choice for a small business website?

No. WordPress is a sensible choice when the editing experience, plugin ecosystem or familiar workflow provides real value. It becomes questionable when the CMS is rarely used but still creates ongoing update, backup and security work.

Can GitHub replace a database?

Not for transactional or fast-changing application data. Git works well for editorial files and reviewed changes. Inventory, reservations, payments, customer sessions and relational queries normally belong in a database, booking platform or specialist API.

Can a non-technical client manage a website without a CMS?

Sometimes. A developer-managed or AI-assisted workflow can prepare repository changes without requiring the client to understand Markdown or Git. The process should still include validation, preview and human review before deployment.

Is a Git-backed CMS completely database-free?

Not necessarily. The canonical content can remain in Git while the CMS uses an index, cache, authentication service or API data layer. The important distinction is which system is the source of truth and what must be restored after a failure.

What should be decided before selecting a CMS?

Define what will be edited, who edits it, how often it changes, whether approval is required, and whether the information is editorial, relational or transactional. Those answers usually make the appropriate architecture much clearer.

Add a CMS only when it earns its place

I do not begin by asking whether WordPress, Drupal, EmDash, TinaCMS or Decap CMS is the best platform. I begin with the people, data and operating workflow.

If a business has a real editorial organisation, complex data or application functionality, a database-driven solution can be exactly right. If the content naturally belongs in files but editors need a visual interface, a Git-driven CMS can be an excellent middle ground. If the website is stable and changes already move through a controlled development workflow, I increasingly ask why another layer is needed.

No CMS does not mean unmanaged content. The content can still be structured, validated, reviewed, versioned, rolled back and backed up.

The principle is simple:

Use a database when the data needs a database. Add a CMS when people genuinely need a CMS. Otherwise, keep the architecture as simple as possible.

If you are deciding how a website should manage pages, guides, properties, bookings or other data, send me the current site and explain who needs to change what. I can help separate the editorial content from the application data and recommend an architecture that remains manageable to operate after launch.