SQLitevsMySQL
A practical comparison of SQLite and MySQL for real-world application workloads. Covers architecture, concurrency, replication, tooling, and the modern SQLite ecosystem (Litestream, Turso, LiteFS) that has changed what SQLite can do in production.
SQLite
A self-contained, serverless, zero-configuration SQL database engine embedded directly into your application. The most deployed database in the world - it ships in every Android phone, every iPhone, every major browser, and countless desktop apps.
Visit websiteMySQL
The world's most popular client-server open-source relational database. Known for its ease of use, mature replication, and a massive ecosystem of hosting providers, tools, and frameworks.
Visit websiteIf you learned databases a decade ago, you probably put SQLite and MySQL in very different mental buckets. SQLite was the database you used for a local cache, a mobile app, or the test suite. MySQL was the database you used when you shipped a real product. That framing is starting to look out of date.
SQLite has had a quiet but substantial decade. STRICT tables gave it strong typing. WAL mode made concurrent reads genuinely fast. UPSERT, window functions, generated columns, and a solid FTS5 full-text search engine closed several of the feature gaps with server databases. The ecosystem has also moved forward: Litestream streams a SQLite database to S3 for continuous backup, LiteFS distributes SQLite across multiple nodes, Turso and Cloudflare D1 offer it as a managed edge service, and Bun shipped first-class SQLite support. For the right workload shape, "just use SQLite" is now a defensible answer in production.
MySQL, for its part, is still the most deployed relational database on the planet. With the 9.x release line under Oracle, it has matured into a rock-solid choice for classic multi-tenant web apps. Group Replication and InnoDB Cluster make high-availability setups less painful than they used to be. HeatWave adds in-database analytics. MariaDB and Percona Server give you drop-in alternatives if Oracle's stewardship worries you. The ecosystem of managed services, hosting providers, and ORMs is unmatched.
The honest comparison is not "which one is better" but "what kind of system are you building." A client-server database like MySQL makes sense when you have many application servers hitting the same data, when write concurrency is high, or when you need fine-grained user and role management. An embedded database like SQLite makes sense when your data lives next to your application, when read performance and operational simplicity matter more than horizontal scale, and when a single-file database you can just copy is a feature rather than a limitation.
This comparison walks through the real trade-offs - architecture, concurrency, deployment story, tooling, and the modern SQLite ecosystem - so you can make that call deliberately.
Feature Comparison
| Feature | SQLite | MySQL |
|---|---|---|
| Design | ||
| Architecture | Embedded library linked into your application; no separate server process | Client-server over TCP or socket; runs as a dedicated database process |
| Deployment | ||
| Setup & Operations | Zero configuration; the database is a file. No users, ports, or daemons to manage | Install server, configure my.cnf, create users, manage backups and replication |
| Performance | ||
| Write Concurrency | Single writer at a time; WAL allows concurrent reads but serializes writes | Many concurrent writers via row-level locking in InnoDB |
| Read Performance | In-process calls - microsecond latency. Often faster than MySQL for read-heavy single-host apps | Fast reads with proper indexing, but every query pays a network round-trip |
| High Availability | ||
| Replication / HA | External: Litestream (streaming backup to S3), LiteFS (distributed), rqlite, Turso; not built in | Built-in async and semi-sync replication, Group Replication, InnoDB Cluster |
| Security | ||
| User / Role Management | None - access control is filesystem permissions on the database file | Full GRANT/REVOKE privilege system with users, roles, and per-table grants |
| Data Types | ||
| JSON Support | JSON1 extension enabled by default; json_extract, json_group_array, path queries | Native JSON type with generated columns for indexing; more mature at scale |
| Vector Search | sqlite-vec and sqlite-vss extensions; works well for moderate-scale semantic search | HeatWave ML offers some vector capabilities; no mainstream community option |
| Query Language | ||
| Full-Text Search | FTS5 module with ranking, prefix queries, and external content tables | FULLTEXT indexes with natural language and boolean modes |
| Limits | ||
| Max Database Size | 281 TB per file; in practice limited by filesystem | 64 TB per InnoDB tablespace; effectively unbounded at the logical level |
| Operations | ||
| Backup Story | Copy the file (or VACUUM INTO); Litestream streams WAL frames to S3 continuously | mysqldump, Percona XtraBackup, or replica snapshotting; more moving parts |
| Developer Experience | ||
| Test Ergonomics | In-memory mode (:memory:) gives a fresh DB in milliseconds per test | Docker containers or shared test databases; slower and more moving parts |
| Licensing | ||
| License | Public domain - no restrictions whatsoever | GPL v2 for Community Edition; proprietary Enterprise Edition |
Design
Deployment
Performance
High Availability
Security
Data Types
Query Language
Limits
Operations
Developer Experience
Licensing
Pros and Cons
Strengths
- Zero configuration - no server process, no port, no user accounts; the database is a single file you can back up with cp
- No network round-trip; query latency is measured in microseconds, which often makes it faster than a remote MySQL for read-heavy workloads
- WAL mode gives you many concurrent readers and non-blocking writes for typical web-app loads
- Extremely small footprint - the library is roughly 600 KB and has no dependencies
- STRICT tables (3.37+), generated columns, window functions, UPSERT, and FTS5 full-text search close most feature gaps with server databases
- Modern ecosystem: Litestream for S3 replication, LiteFS for distributed SQLite, Turso and Cloudflare D1 for managed hosting, sqlite-vec for vector search
- In-memory mode makes unit and integration tests trivial - spin up a fresh database per test in milliseconds
- The file format is guaranteed stable through 2050 by the SQLite project, which is better than most cloud databases can promise
Weaknesses
- Single-writer at a time - WAL enables many concurrent readers, but only one transaction can commit at once
- No built-in network protocol; remote access requires wrapping it (libSQL/Turso, Cloudflare D1, rqlite, or a custom API)
- No user or role management - access control is whatever the filesystem permissions give you
- Loose type affinity by default; you need STRICT tables or CHECK constraints to enforce types rigorously
- Limited ALTER TABLE compared to MySQL - some schema changes require a table rebuild
- Horizontal scaling is an ecosystem concern (LiteFS, rqlite), not a built-in feature
Strengths
- Genuine multi-writer concurrency - many application servers can write to the same database simultaneously
- Mature replication options: async, semi-sync, Group Replication, InnoDB Cluster, and InnoDB ReplicaSet
- Built-in user accounts, roles, and fine-grained privilege management
- Massive ecosystem - almost every ORM, framework, and hosting provider supports MySQL first-class
- Thread-per-connection model handles thousands of concurrent connections without extra infrastructure
- HeatWave engine adds in-database analytics and ML without moving data to a warehouse
- Drop-in compatible alternatives (MariaDB, Percona Server) and managed offerings everywhere (RDS, PlanetScale, etc.)
Weaknesses
- Operational overhead - you run a server, manage users, tune memory, and monitor uptime even for small apps
- Network round-trip on every query adds latency compared to an embedded engine
- Requires a deployment target for the server itself - not an option for mobile apps, CLIs, or single-binary distributions
- Harder to replicate the full test story SQLite gives you (per-test in-memory databases are more awkward)
- Oracle's stewardship adds a small but real amount of long-term licensing uncertainty for the community edition
Decision Matrix
Pick this if...
You are building a CLI tool, desktop app, or mobile app with bundled storage
You have many application servers, workers, or services writing to the same database at once
You are deploying to edge runtimes (Cloudflare Workers, Fly, Deno Deploy)
You need fine-grained user accounts, roles, and SQL-level privileges
Your test suite needs fast per-test isolated databases
You run WordPress, Drupal, or another CMS that assumes MySQL
You want the simplest possible operational story (no server, no users, backups = cp)
Your database must be shared across multiple language runtimes or independent services
Use Cases
A CLI tool, desktop app, or mobile app that needs a local embedded database
This is SQLite's home ground. Ship a single binary with an embedded database and you are done. No install scripts, no version mismatches, no daemon to keep alive. Android, iOS, Firefox, and most desktop apps already bundle SQLite for a reason.
A backend where multiple services, workers, or runtimes need to write to the same database concurrently
MySQL's client-server model is built for this. Any number of app processes, background workers, cron jobs, or polyglot services can hold connections and write in parallel without coordinating through a single-writer queue. SQLite can be made to work here with LiteFS or a proxy layer, but you are fighting its design.
A multi-tenant SaaS with many concurrent writers across multiple application servers
SQLite's single-writer limitation becomes painful once you have significant write concurrency from multiple processes. MySQL's InnoDB row-level locking handles this profile natively, and horizontal replication lets you scale reads across replicas.
A test suite that needs to spin up and tear down databases per test
SQLite's :memory: mode gives you a completely isolated database in milliseconds. Every test gets a clean slate without Docker containers, shared schemas, or per-test cleanup scripts. The speedup on large test suites is dramatic.
A classic LAMP-stack web app (WordPress, Drupal, or similar CMS)
These platforms assume MySQL. Running them on SQLite is possible but fights the entire ecosystem - plugins, migrations, and tutorials all assume a MySQL-compatible server. Use the database the platform was designed around.
An edge-deployed application that needs low-latency data close to users
Turso (libSQL) and Cloudflare D1 make SQLite the natural fit for edge compute. Replicate a SQLite database to every region and queries run locally at each edge node. A traditional MySQL setup requires more infrastructure to get similar latency.
Verdict
MySQL remains the right default for most server-side web applications in 2026 - it is the most deployed relational database in the world, has mature replication and high-availability options, genuine multi-writer concurrency, and an ecosystem of hosting providers and tooling that is unmatched. SQLite has earned a legitimate seat at the production table for a specific and growing set of shapes: embedded apps, CLI tools, single-server read-heavy services, test suites, and edge-deployed applications. Tools like Litestream, LiteFS, Turso, and Cloudflare D1 have changed what 'production SQLite' means, but the architectural split still matters - pick the one whose shape matches the system you are actually building.
Our Recommendation
Pick MySQL when you need true multi-writer concurrency across application servers, built-in user management, or the deepest possible ecosystem of tools and hosting providers - which covers most classic web app shapes. Pick SQLite when operational simplicity, in-process read latency, embeddability, or edge deployment are the dominant requirements.
Frequently Asked Questions
Related Comparisons
Found an issue?