Do you always need a database for your app?

Do you always need a database for your app? Of course not.

As with everything in technology, nothing is ideal in every situation.

Computers offer many various ways to store data. The most obvious alternative is files.

A common example is a CMS. Some CMS use a database to store data (think WordPress), some others prefer to store data using files (think Grav or Statamic).

Not using a database in that case means a simpler deploy to a hosting service. There is no server to provision, no credentials to manage, no backup job for a separate system. The content is right there in the repository, and version control gives you history for free.

Files start to hurt when you need to query. “Give me the ten most recent posts tagged ‘go’ by this author” is one line of SQL, and a pile of custom code over a folder of files. Files also get risky when several processes write at the same time: two concurrent writes to the same file can corrupt it, and you end up reinventing locking.

But when handling lots of data, a database is definitely a great way to simplify your life in the long term.

If you are building a macOS or iOS app, you might decide that a JSON or Plist file is all you need to handle data, because the user does not need to store a lot of it.

Or maybe Core Data (a wrapper for an internal SQLite database) is best for you.

The middle ground: an embedded database

There’s a big space between “a JSON file” and “run a PostgreSQL server”, and SQLite fills it.

SQLite gives you real SQL, indexes, constraints, and transactions, but the whole database is one ordinary file inside your app’s folder. Nothing to install on the user’s machine, nothing to keep running. That’s why so many desktop and mobile apps use it without you ever noticing.

My rule of thumb: reach for plain files when the data is small, rarely queried, and written by one process. Reach for SQLite when you want to query or when writes can overlap. Reach for a database server when several machines need to write to the same data over the network.

As always, it’s all a balance of complexity vs convenience.

If you decide you do need one and don’t know which, I built a free database chooser that asks a few questions and points you to SQLite, Postgres, a KV store, or a columnar database.