Database

A database is more than a big spreadsheet. A spreadsheet is a file one person usually opens at a time; a database is a service that many visitors and staff can read from and write to at once, with rules that keep the data consistent. Most websites with a CMS, a shop or logins have a database behind them, even if the owner never sees it.

The database is usually the most valuable part of a site. Templates and code can be rebuilt; years of orders, enquiries and customer history cannot. That makes backups and access control the parts that matter most to an owner.

How it works

The most common kind is a relational database, such as MySQL, MariaDB or PostgreSQL. It stores data in tables made of rows and columns: one table for customers, one for orders, one for products. Each row has a unique ID, and tables refer to each other through those IDs, so an order row records which customer placed it rather than copying their name and address.

Application code talks to the database in SQL, asking for exactly the rows it needs, such as "all bookings for next Tuesday". To keep those questions fast, the database maintains indexes, sorted lists that work like the index in a book. It also uses transactions, which group several changes so that they either all happen or none do, so a payment is never recorded without its order.

Other kinds exist for different jobs. Document databases store flexible records that do not fit neat tables, key-value stores hold quick lookups such as session data, and a vector database stores numerical representations of text for AI search. For a typical business site, a relational database is the default and usually the right choice.

Example

A WordPress site keeps its pages, blog posts, settings, users and form entries in a MySQL or MariaDB database, while images sit as files on the server. When a visitor opens a blog post, the CMS asks the database for that post's title, text and author, inserts them into the template and sends the finished page.

The site's host is hacked and the server is wiped. The owner had nightly file backups but had assumed the database was included, and it was not. The design is restored in an hour from the files, but every post and form entry since launch is gone. The next host is set up to back up the database separately and keep copies off the server.

Why it matters for your business

Your database holds the information your business would struggle to recreate, and in many cases personal data you are legally responsible for under rules such as GDPR. The practical questions for an owner are simple: is it backed up automatically, are the backups stored somewhere other than the same server, has anyone ever restored one to prove it works, and who has access. A database that is slow or full of years of spam entries also slows the whole site down.

Common mistakes

• Backing up a site's files but not its database, or storing the only backup on the same server.
• Sharing one database login with full rights among everyone who works on the site.
• Keeping years of spam submissions, old revisions and expired sessions that make every query slower.
• Storing personal data nobody needs and making a breach worse than it had to be.

Questions people ask

Does my website have a database?

If it runs on a CMS such as WordPress, has a shop, user accounts or forms that store entries, it almost certainly does. A purely static site built from ready-made HTML files usually does not. Your hosting control panel normally lists any databases attached to your account.

How often should a database be backed up?

As often as you can afford to lose changes. A site that takes orders or bookings every day needs at least daily backups, and busy shops often back up more frequently. A brochure site that rarely changes can back up less often. Test a restore occasionally.

What is the difference between a database and a spreadsheet?

A spreadsheet is a document designed for people to view and edit directly. A database is a service designed for software to query, with many users reading and writing at once, strict rules on data types and relationships, and the ability to handle far more records quickly.