Not all websites need a database.
I was just drooling over the new Mac Studio landing page on apple.com. It’s a beautiful piece of web design that serves an important purpose for a big company, and really doesn’t need any technology other than HTML, CSS, and JavaScript. “Brochure” sites like this are classic examples of sites that don’t need a database. You’ll sometimes hear them called “awards” sites, as they tend to be beautifully focused one-offs that don’t need to live forever within a long-lasting system.
Even sites with a lot more pages don’t necessarily need a database. You can just duplicate directories or HTML files for a while, even if it is a little repetitive. Modern code editors make updating repetitive code in a code base no sweat.
At some point, sites with a ton of pages benefit from a more robust templating system. Blog posts use this template, landing pages use this template, etc.
Combining content with templates to produce a page can be done a number of ways and entirely without a database.
- A website with access to a backend language can use that backend language to do the content+template creation on request.
- A website builder tool with a build process can produce static HTML output from content+template before the files are deployed to the server.
So yeah! You can get pretty far without needing a database at all. Perhaps the most common approach is using a static site generator, of which there are many. Frontend Masters has courses on site builders that can produce static sites like Next.js, Nuxt, and Astro.
So then when? When do you make the call that for some particular product, a database is the right decision.
When You Probably Need a Database
- When you have a log in system. You might be able to get away with not storing user auth information at all (e.g. “social auth” only), but even then, those users are likely doing something with your website and if you need to save what they are doing, you need to associate it with that user, and a database will be the way. If you want to let a user log in and do things, perhaps even across devices, you’ll be storing what they are doing and like their last “state” of what they are doing in a database.
- When you have very dynamic data. “Dynamic” meaning changing often. Imagine forums. Users logging in and creating new threads and responding to existing threads. It’s probably not practical to be forcing some build process to run rebuilding static files in a forum. Forum data makes much more sense in a database, especially as it can then be retrieved and used in many different ways (recent posts, individual threads, user profiles, etc.) Comment sections are similar and something that a database is generally in charge of.
- When you have relational data. Imagine a real estate app where the users are realtors, realtors represent homes, but a home might have multiple realtors, and those realtors belong to realtor groups, etc. These are all tables of data that can reference each other and is the strength (and point) of relational databases like Postgres. (see a Complete Intro to SQL & PostgreSQL)
- When you present things that need to be search, filtered, or sorted. A database excels at jobs like “give me these specific things sorted in descending order by date” or the like. Producing static files of every possible search, sort, or filtering choice (assuming you can’t do that filtering client side) isn’t usually practical.
- When you just have too much. Just to draw a reasonable line, I’d say at over 100 pages, unless they are super similar types like only blog posts, it’s likely a site benefits from keeping the content for those pages in a database. It might not be “pages” only, it could be users, products, songs, or whatever the main things of the website are.
What are the downsides of a database then? What does it cost you?
It seems like there are a lot of upsides to a database, doesn’t there? It really does a lot for a website and is all but a requirement for bigger and more feature rich websites. What’s so nice about not having one, such that there are specific tools to avoid it?
- Databases are more expensive. Hosting that does not include a database tends to be cheaper. Netlify, a classic host built upon a foundation of hosting only static files, has an entirely free plan. A database host might be an entirely separate hosted service which may come with it’s own costs.
- Databases require security. Databases are usually necessarily accessible on the open web or at least on the private network that the website backend has access to. They also tend to contain sensitive data like private user information. If a nefarious user got more access to the database than they should have, they could download that private information and/or corrupt what is there. This is unfortunately not a maybe. Insecure databases will almost certainly be messed with.
- Databases require backups. Because of the risk of nefarious behavior, and even more likely, your own team making honest mistakes, you need to have backups of the database as often as possible. When dealing with flat files, your Git repository and previous deployments act as your backups, but that doesn’t cover a database. Databases need their own unique backup systems.
- Databases require maintenance. Database software can update versions, which can include security patches. Add this to your list of responsibilities.
- Databases require a backend language and ORM. Front-end code doesn’t typically talk directly to a database. It talks to back-end code which talks to a database. And even back-end code typically isn’t raw SQL queries and the like, it uses an ORM (e.g. Prisma) that provide a more friendly abstracted syntax for dealing with data. When you work with a database, ends up being lots of additional technology that layers onto your stack to make it all work together.
- Databases likely need a migration strategy. Just having and using a database is work, but the structure of a database has a habit of needing to change. Imagine needing to add an additional column to the database, or change the name or structure of the data within a table. These changes are called migrations and have their own set of complexity that might become your job.
Implied Databases
This isn’t to say that all of this is immediately your problem when using a site that makes use of a database. For instance, this is a WordPress websites as I write, which has an SQL database. But we didn’t have to write APIs for it and we don’t deal with migrations for it, and the backups. Most WordPress websites I’ve worked with have implied security through the hosting and backups handled by paid plugins.
So using pre-existing software that makes use of a database is a different situation than an entirely custom project that grows into needing a custom database.
Types of Databases
It should also be noted that databases come in lots of different shapes and sizes.
- A K:V store (key: value) is perhaps the simplest possible database. This is the foundation of software like Redis and you’ll see companies like Cloudflare offer stores like this.
- Some databases are “schema-less” in that the bits of data have no defined types, and are more JSON-like in nature like CouchDB, MongoDB, Firebase, etc.
- Some databases come in the form of hosted services and are content-focused like Sanity and Contentful.
- Even “classic” databases like SQL come in varietals like Postgres and MariaDB. And these have dedicated hosts like SQL has PlanetScale and Cockroach and Postgres has Supabase.
Some websites do need a database! Good luck!
