SQLite vs MySQL vs PostgreSQL
By now you know SQLite well enough to ask the real question: when should you actually reach for it, versus MySQL or PostgreSQL? The honest answer isn't "SQLite is simpler so it's worse" — it's that these are different tools built for different jobs, and picking the right one for the situation in front of you matters more than picking the "best" one in the abstract.
The Core Architectural Difference
Everything else in this comparison flows from one fact: SQLite is embedded and serverless, while MySQL and PostgreSQL are client-server.
| SQLite | MySQL / PostgreSQL | |
|---|---|---|
| Architecture | A library linked into your app; reads/writes a local file directly | A separate server process; apps connect to it over a network (even if that network is just localhost) |
| Setup | Nothing to install or run — the database is the file | A server to install, configure, and keep running |
| Where the data lives | One file, wherever the app puts it — on the same device as the app | On the database server, potentially a different machine from any client |
| Multiple apps sharing data | Awkward — not built for many separate applications reading/writing the same database over a network | Exactly what it's built for — many clients, potentially on many machines, all talking to one server |
Where SQLite Is the Better Choice
RecipeBox as a mobile or desktop app is a textbook SQLite use case — and so are a lot of other real, common situations:
- Mobile apps — RecipeBox's own local data on a phone. No server to run, and the data lives with the app, which is exactly what Android's own storage (via Room) is built on.
- Desktop applications — local app data that doesn't need to be shared over a network, stored in one portable file.
- Small-to-medium websites — a content site, an internal tool, or a low-traffic app where a full separate database server is genuinely unnecessary overhead.
- Prototyping and testing — spin up a real, correct SQL database with zero setup, iterate fast, and optionally swap in MySQL/PostgreSQL later since the SQL skills transfer directly.
- An application file format — plenty of real apps (browsers, editors, and more) use a
.sqlitefile as their actual save-file format, since it's just one portable file with a real query language built in.
Where MySQL / PostgreSQL Are the Better Choice
- High-concurrency, multi-user server workloads — many simultaneous writers hitting the same database at once. SQLite's WAL mode genuinely helps concurrent readers and a writer coexist, but SQLite still serializes writers one at a time, which becomes a real bottleneck under heavy concurrent write load in a way a client-server database is built to handle.
- A shared database multiple separate applications connect to over a network — the client-server model is exactly built for this; SQLite's single local file is not.
- User privilege management — needing different accounts with different, enforced permissions on the same database, which SQLite has no built-in mechanism for at all (see Security Best Practices).
- Replication — keeping synchronized copies of a database across multiple servers for redundancy or read-scaling, a well-developed feature in MySQL/PostgreSQL that SQLite doesn't provide natively.
- Very large, multi-terabyte datasets — server databases are built and tuned for this scale of storage and query load in a way a single local file isn't targeting.
Decision Guide
| If your situation is… | Reach for… |
|---|---|
| A mobile or desktop app storing its own local data | SQLite |
| A prototype, a small tool, or you're just learning SQL | SQLite |
| An app's save-file format, or embedded config/cache storage | SQLite |
| A website or service with real concurrent multi-user traffic | MySQL / PostgreSQL |
| Multiple separate applications need to share one database over a network | MySQL / PostgreSQL |
| You need per-user database privileges, replication, or very large scale | MySQL / PostgreSQL |
What Doesn't Change Between Them
It's worth remembering how much you already know that transfers directly: SELECT,
JOIN, GROUP BY, transactions, indexes, constraints — the core
relational SQL this entire track has taught works, with minor dialect differences, across
SQLite, MySQL, and PostgreSQL alike. Choosing SQLite for RecipeBox today doesn't strand that
knowledge if a future version of the app ever needs a client-server database instead.