Databases for People Who Do Not Use Them

Your pages are not files

The assumption most people carry is that a website is a set of pages sitting on a server, in the way a folder holds documents.

On most small business sites that is not how it works.

The text of your pages, your posts, your settings, your customers, and your orders are stored in a database, and the pages are assembled when somebody asks for them.

Once that is understood, several otherwise arbitrary behaviours make sense, and the practical consequences follow directly.

What a database actually is

For this purpose, a set of tables, each with rows and columns, like a collection of spreadsheets that can reference each other.

One table holds pages and posts. Another holds settings. Another holds users. A shop adds tables for products, orders, and customers.

When somebody requests a page, the site looks up the relevant rows, combines them with the template, and sends the result.

That happens on every visit, which is the important part: the page does not exist until somebody asks for it.

The consequences that matter

• A file backup is incomplete without the database.
• Assembly takes time, which is why sites can be slow.
• Caching helps by storing the assembled result.
• A database problem takes the whole site down at once.
• Content cannot be recovered from the server files.
• Moving a site means moving two things, not one.

The first is the one that costs businesses real work. A backup containing only the files restores a working installation with no content in it.

Why the site is slow

The explanation people find most useful.

Every visit means work: several database queries, then assembly, then sending. On a shared server with a busy database that adds up.

Which is why a site with very few pages can still be slow, and why the answer is frequently caching rather than a faster server.

Caching stores the assembled page and serves it directly to the next visitor, skipping the database entirely, and it is usually the single largest improvement available.

It also explains why an update sometimes does not appear immediately: the cached version is still being served until it expires or is cleared.

Why it breaks

Database problems produce a distinctive kind of failure worth recognising.

The site returns an error mentioning a database connection, or a blank page, or every page fails at once while the server itself is clearly running.

Common causes are the database server being overloaded, a corrupted table, credentials changing after a migration, or the account exceeding a limit.

None of that is visible in the files, which is why looking at the site's folder tells you nothing.

It is also why the honest answer to a database error is usually to contact your host rather than to attempt anything, since the tools involved can lose data quickly.

A worked example

A business took what they believed were regular backups: a download of the site folder, monthly, to a drive in the office.

After a hosting problem they attempted to restore, and got a working installation with no pages, no posts, no settings, and no customers.

All of that had been in the database, which had never been included.

They recovered most of it from their host's own backup, which went back eleven days, and lost the rest.

Their monthly routine had felt like diligence for two years and had been backing up the shell of a site.

The correction was small: the same routine, with a database export included, which their host provided as a single option they had never selected.

What to actually do about it

Three things, none of which requires understanding databases.

Confirm your backups include the database, by looking at what the backup contains rather than trusting that it does.

Enable caching, which most hosts and platforms offer as a setting, and learn where the clear cache button is so an update that has not appeared is not a mystery.

And keep the database credentials with your other access details, since a migration or a restore needs them and they are stored in a configuration file nobody can find under pressure.

Beyond that, this is a subject to understand rather than to administer.

The one thing not to do

Worth stating plainly because the tools are sitting in the hosting panel.

Do not edit the database directly to fix something, however small the change looks.

A wrong value in the wrong table can take the site down, expose content, or corrupt relationships between records in ways that are not obvious for weeks.

There is also no undo, and no confirmation step in most of these tools.

Anything requiring a database change is a job for whoever maintains the site, and if that is you, take a database backup immediately before touching anything.

The counter-case

Not every site works this way, and the distinction is worth knowing.

Sites built as plain files, including those produced by some modern tools, genuinely are folders of pages, and for those a file backup is complete and there is no database to break.

Those sites are faster and simpler by design, at the cost of being harder for a non-technical person to update.

If your site was hand-built or produced by a static generator, most of this article does not apply to you, and knowing that is itself useful.

Ask which kind you have, since it changes what a backup means and what can go wrong.

The check

1. Ask whether your site uses a database.
2. Open a backup and confirm the database is in it.
3. Enable caching if it is not already on.
4. Learn where the clear cache option is.
5. Store the database credentials with your other access.
6. Never edit it directly without a backup taken first.
7. Contact your host for any database error.

Step two is the one that matters, and a surprising number of careful businesses discover their backups have been incomplete for years.

Where hosting limits your site is covered in hosting that is the bottleneck.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.