Databases Compared
SQLite vs MySQL: When the Embedded Engine Wins
SQLite and MySQL differ structurally before they ever differ in speed: SQLite is an embedded library that reads and writes a file in your application's directory, and MySQL is a server with a network stack, users, privileges, and a daemon to run. SQLite wins everywhere the app owns its data: read-heavy sites, caches embedded in larger apps, development copies, per-site tenant databases on cheap hosting, and anything local-first. MySQL wins on concurrent multi-writer production traffic, service-managed replication, backups judged by DBAs, and the cPanel-era hosting reality where the server handles ten sites' privileges and one daemon gets patched once. The casual comparison 'SQLite is a toy database' is wrong; the honest limit is a single writer at a time, which most personal and small-business loads never approach.
Key points
- Start structural: SQLite is a file the application opens; MySQL is a service with users, ports, grants, and its own process tree. Most choice consequences follow from that alone.
- SQLite's concurrency truth: many readers can proceed at once (better in WAL mode), but writers queue one at a time; know your write curve before betting a production site.
- Ops weight is the hidden cost axis: comptime-ship SQLite with no daemon to run, upgrade, patch, or back up separately, while MySQL earns its DBA hours honestly.
- Multi-tenant hosting still trends MySQL: cPanel-era hosting, CloudLinux-friendly stacks, and shared hosting administration assume one database server handling many tenants' grants.
- SQLite's read performance embarrasses its marketing assumptions: for read-heavy, small-data estates it frequently beats MySQL with no tuning at all.
- For cheap hosting plans, SQLite has been quietly viable for a decade: one .sqlite file among the site files, backed up by the same rsync as everything else.
- Integrity and trunk stability are SQLite strengths: the same file format has been the standard since version 3 (2004), which laughs at any five-year schema migration.
- Pick MySQL when writes become concurrent and nobody wants to own the locking drama, or when the hosting account bills the database server separately and it should earn it.
Field note
Our per-tenant pattern shipped an app that kept one SQLite file per site and the quiet read-heavy ones performed beautifully; then one tenant's nightly batch job met the single-writer ceiling and taught us the whole lesson. Design around write concurrency and SQLite is not a toy database.
Frequently asked questions
Is SQLite ever right for a website?
Yes: read-heavy small sites, per-tenant files, caches, and development copies; the classic warning assumes write concurrency the site never actually has.
Does SQLite have real SQL?
A substantial subset: transactions, most joins, indexes, and triggers all work; what's missing is concurrent multi-writer semantics, not literacy.
When must we choose MySQL instead?
When multiple processes write concurrently, when you need service-managed replication/runs, or when the existing estate already runs database ops.
Is SQLite production-safe?
Its track record says so: massive deployment base, file format stability, and enormous amounts of production traffic behind boring, quiet years.
How Kinetikatech helps with databases compared
This is what we do every day: Database engine choices for hosting workloads, compared on correctness guarantees, operational weight, and real cost: embedded engines against servers, MySQL against PostgreSQL, SQL against document stores, plus the legacy case study that keeps coming back. Our Server Management and Website Speed Optimization service covers it end to end, assessment, implementation, 24/7 monitoring, and emergency response within 30 minutes.