Not Everything Needs a Database

Modern development makes it incredibly easy to add a database to a project. A few environment variables, a client library, and you can start storing almost anything. But just because something can be stored doesn't mean it needs persistent storage.

Start with the question: does this data need to persist?

If information can be derived from existing data, generated at runtime, or kept temporarily in memory, introducing another persistence layer may create unnecessary complexity. The database should solve a real requirement rather than simply being part of the standard stack.

Static content is often better kept static

A portfolio, marketing website, documentation page, or small business site may not need a database at all. If the content changes occasionally and can be managed through code or a simple CMS, adding database queries to every page can introduce complexity without providing meaningful value.

Use a database when the product actually has state

Accounts, orders, bookings, inventory, messages, subscriptions, permissions, and user-generated content are examples where persistent storage becomes essential. These systems need information to survive between requests and remain consistent across users and devices.

Architecture should follow requirements

The right technology stack depends on what the product actually needs. Starting with the smallest architecture that can support the requirements makes a system easier to understand, deploy, maintain, and eventually scale.

Good engineering isn't about using more infrastructure. It's about introducing the right infrastructure at the right time.