When you need a database

Use a database when data must survive restarts, be queried in several ways, enforce relationships, or support concurrent changes.

You do not need one for every program. A static configuration file or an in-memory array can be the simpler tool when the data is small and does not change independently.

Take a settings file:

{
  "theme": "dark",
  "language": "en"
}

This data is read at startup, changes rarely, and is always loaded whole. A JSON file is the right tool here. A database would add setup and complexity for zero benefit.

Now look at the four signals from the first sentence, one at a time.

Survive restarts. Data held in memory disappears when the process stops. If losing it is a problem, you need durable storage: a file at minimum, a database when the other signals show up too.

Queried in several ways. A file is easy to read top to bottom. But a question like “all orders from March, grouped by customer, newest first” means loading everything and filtering in your own code. A database answers questions like that directly, and stays fast as the data grows.

Enforce relationships. When an order must always point at a real customer, a file leaves that rule to your code, in every code path, forever. A database enforces it once, at the storage layer.

Concurrent changes. This is the one that breaks file-based storage in practice. Picture two requests updating the same JSON file: both read it, both modify their own copy, both write it back. The second write silently erases the first one’s change. That is a lost update, and you usually discover it weeks later as missing data. A database serializes writes and gives you transactions, so this class of bug disappears.

Start with the requirements: what must be stored, who changes it, and how it must be retrieved. One process, small data, whole-file reads: keep the file. Several writers, several questions, rules to enforce: that is a database.