SQLite vs MySQL: When a File Beats a Server

The SQLite-vs-MySQL debate usually starts from tribal loyalty. Let me skip that and compare them the way I actually decide: as a file you own versus a server you administer.

SQLite: the file that is a database

• Zero operations. There is no daemon, no port, no connection pool to tune. Your app opens a file.
• Backups are trivial. Stop (or use VACUUM INTO while running), copy, done.
• Perfect for one machine. If your service runs on a single node and reads more than it writes, SQLite handles it comfortably.
• The limits are real. One writer at a time. No replication. No network access. You cannot shard a file.

MySQL: the database server

• Concurrency and scale. Multiple writers, bigger workloads, replication, and a whole ecosystem of tooling exist for a reason.
• Operations are now your job. A server means backups, upgrades, connection limits, and "why is the query slow" investigations.
• Worth it when you outgrow a file. The moment you need multiple writers, replicas, or data beyond what a single file should hold.

How I choose

Three questions:

1. Does it run on one machine? Yes → SQLite is a serious candidate. No → server database.
2. How many concurrent writers? More than a few → MySQL. Mostly reads and modest writes → SQLite.
3. Who operates it? If I am the only operator, SQLite's zero-ops is priceless. If a team already runs database servers, MySQL's tooling wins.

The honest answer

For a solo developer's web service that fits on one node, SQLite is not a compromise — it is the better tool: less to install, less to secure, less to back up, and it removes an entire class of operational work. You switch to MySQL when the workload genuinely demands a server, not because "real projects use MySQL."

Estimate the size of the file you would be managing with the calculator below — it is usually smaller than people fear.