Databases for business websites: when you need one and when you do not
Whether a business website needs a database at all, why the ones that do need a managed one, and how to tell which you are.
The short answer
A database stores data that changes because of what users do: accounts, orders, bookings, submissions, messages, inventory. Content that your team edits, pages, articles, service descriptions, case studies, does not need one; it lives as files in the repository, versioned like code, and is built into pages ahead of time. That is why a brochure site, a knowledge base, a portfolio and a marketing site run with no database at all, which removes a whole category of cost, maintenance and risk. When a site does need one, because visitors write data the business must keep, a managed database service in a region near your users, in your own account, with automated and tested backups, is the right answer. The deciding question is simple: what data must be written by visitors and kept? If the answer is nothing, or only submissions that an email and an automation handle, you do not need a database.
Do you need one?
| The site does | Database? | Why |
|---|---|---|
| Pages, articles, services, cases edited by your team | No | Content as files, built into pages |
| A contact form that emails and forwards to a CRM | No | The CRM is the store; the site just passes it on |
| Newsletter sign-up | No | The marketing platform stores subscribers |
| Payments for a few products | Usually no | The payment provider and store platform hold orders |
| A store with catalogue, cart and orders | Yes, or a store platform’s | Orders and inventory are user-written data |
| Bookings with availability | Yes, or a booking service’s | Availability changes with every booking |
| Customer accounts and logged-in areas | Yes | Accounts are the definition of user data |
| A portal or an application | Yes | Data is the product |
| Submissions that must be kept beyond email for compliance | Yes, small | A record with retention rules |
When you need one, do it right
- Choose a managed service in an account in your name.
- Pick the region for your users and your data residency needs.
- Restrict access: the site’s functions connect with a least-privilege role; nothing is open to the internet; humans use their own accounts.
- Automate backups and test a restore before launch, then periodically.
- Version the structure: every change to tables is a migration in the repository, reviewed and reversible.
- Keep secrets in secret storage, never in code.
- Monitor size, slow queries and errors; set alerts.
- Define retention: what is deleted when, especially for personal data.
What changes without one
No monthly database fee. No backups to test for the site itself. No migrations. No injection attacks against content. No slow queries under load, because there are no queries. The site is files served from an edge network, and the dynamic edges, forms and payments, hand their data to systems built to hold it. For a business website that is not a compromise; it is the better architecture.
What this means for you
Decide whether your site needs a database by asking what data visitors write that the site itself must keep. A business site needs none and is better without. When one is needed, use a managed service in your own account and region, restrict access, automate and test backups, version the structure and define retention. The database is either absent or properly run; the middle ground of a database bolted to a website is where the incidents come from.
Frequently asked questions
Our current site has a database. Does the new one need one?
Probably not for the same reasons. Traditional platforms store all content in a database because that is how they work, not because the content needs it. A rebuilt site stores content as files in the repository, versioned and built into pages, and only needs a database if visitors write data: accounts, orders, bookings, submissions worth keeping beyond an email. Many businesses discover their site needs none.
What does having a database add to running a site?
A service to pay for and size, backups to take and test, access to control, a region to choose for data residency, migrations when the structure changes, and a component that can be slow, full or compromised. None of that is difficult with a managed service, but all of it is real, which is why a site that does not need one is better off without.
Where should the database live?
With a managed provider, in a region that suits your users and your data residency requirements, in an account in your name, with automated backups you have tested restoring. Not on a server you run yourself unless you have someone whose job it is to run databases. The managed service handles patches, failover and backups for a monthly fee that is small compared with one recovery.