In short
A website needs a database only if it stores information that changes while the site is running: user accounts, orders, comments, bookings, content edited by many people, or data that visitors search and filter. A marketing site, portfolio, documentation site or blog edited by one or two people does not; its content can live in files and be published as static pages, which is faster, cheaper and far harder to hack. If in doubt, start without one and add it when a feature genuinely requires it.
What a database is for
A database is a system for storing structured information that can be read, written and searched by a program while it runs. Websites use one to hold things that change: who has an account and what they are allowed to see, what has been ordered, what someone commented, which appointments are booked, which products are in stock.
The key word is while it runs. If the only thing that changes on a site is its content, and the content changes when someone edits it rather than when a visitor does something, the site does not need a database at all. The content can be files, and the site can be built from them.
The test
Ask, for every feature: does a visitor's action need to be remembered by the site?
- A visitor reads a page: no.
- A visitor submits a contact form that emails you: no, the email is the record.
- A visitor logs in: yes.
- A visitor adds an item to a cart that survives a page reload: yes, or at least some storage.
- A visitor comments and the comment appears to others: yes.
- A visitor books a slot and the slot becomes unavailable: yes.
- A visitor filters two hundred products by size and colour: probably yes, though small catalogues can be filtered in the browser.
- An editor updates the pricing page: no, that is a content change.
If every answer is no, the site is static. It may still be built with a CMS for the editors' convenience, but the published site needs no database, and that is the static versus dynamic distinction in practice.
Sites that do not need one
Marketing sites, agency and studio sites, portfolios, restaurant and local business sites, documentation, brochures, landing pages, event pages, and blogs or article libraries edited by a small team. This site is an example: hundreds of articles, a contact form, a booking flow, and the published pages are static files. Where a feature needs to remember something, such as the booking slots, a small file-based store does the job without a database server.
For these sites, a database is a cost with no benefit: slower pages, a server to run, a login to protect, updates to apply, and the single most common way small sites get compromised.
Sites that do
Anything with accounts. Users, permissions, sessions, passwords. This is the line: once people log in, you have a database, and with it the authentication and security obligations that follow.
E-commerce beyond a few products. Orders, inventory, customers, and the search and filtering that a catalogue needs. Small shops can use a hosted platform that provides the database as a service; that is still a database, just someone else's.
User-generated content. Comments, reviews, forums, uploads that others see.
Bookings, reservations and inventory where a visitor's action changes what is available to the next visitor.
Large catalogues and directories that visitors search and filter, where the data is too large or too dynamic to ship to the browser.
Content edited by many people with workflow. A newsroom with dozens of editors, drafts, review and scheduling. A database-backed CMS earns its keep here; a two-person blog does not need it.
Web applications. If it is software rather than a site, it has a database. That is a different category with a different architecture decision behind it.
The alternatives in between
Files. A folder of Markdown or JSON, edited in a text editor or through a simple admin, built into pages. This handles content for most sites and small structured data such as a list of team members or a price table.
A headless CMS. Editors get a friendly interface; the site fetches content at build time and publishes static pages. The database exists, but it belongs to the CMS vendor and never touches your visitors. This is the pattern for sites that need non-technical editing without running a server.
Hosted services for the one dynamic feature. A form service, a booking tool, a comments provider, a payment link. The site stays static and embeds or links to the service that has the database. Right for a site with a single feature that needs memory.
A hosted database. When you do need your own, services such as Supabase, PlanetScale, Neon or the cloud providers' managed offerings give you a database without a server to administer. The security and schema decisions remain yours; the backups and patching do not.
What having a database commits you to
A server or service that must stay up. Backups, tested by restoring them. Security updates. Access control and secrets management. A schema that someone designed and that will need migrations as the product changes. Monitoring. Privacy obligations for any personal data it holds, including deletion on request. None of this is difficult in isolation; all of it is ongoing, and none of it exists for a static site.
The sensible default
Start without one. Build the site as static pages, use a file-based store or a hosted service for the first feature that needs memory, and add a real database at the point a feature genuinely requires it, with the obligations above understood. Sites that begin with a database because the template came with one carry its costs for years without using it.
If you are unsure which side of the line a planned site falls on, book a call; it is usually a ten-minute conversation about which features need to remember things.
Common questions
Do I need a database for a small business website?
Almost never. A site that presents services, prices, contact details and articles, with a form that emails you, stores nothing while it runs and can be published as static pages. A database becomes necessary when visitors log in, order, book slots that become unavailable, or post content others see.
Does a blog need a database?
Not if it is edited by one or a few people. Posts can be files built into static pages, or managed in a headless CMS whose database never touches the public site. A database-backed CMS such as WordPress is a convenience for editors, not a requirement for publishing, and it brings hosting, update and security obligations.
Does a contact form need a database?
No. A form can send an email, post to a form service, or append to a simple file; the email or the service is the record. Storing submissions in a database is useful only if you need to search or manage them within the site, and it makes the site responsible for protecting the personal data it holds.
What is the difference between a static website and a database-driven website?
A static site is a set of prebuilt pages served as files; nothing changes while it runs, so it is fast, cheap to host and very hard to hack. A database-driven site builds pages on request from stored data, which allows accounts, orders and user content but requires a server, a database, updates and security work.
Can I add a database to a website later?
Yes, and it is the sensible order. Start static, use a hosted service for the first feature that needs memory, and introduce a database when a feature genuinely requires one. Adding it later means the site pays the database's costs only from the point it delivers a benefit.
