PostgreSQL vs MySQL vs SQLite: which one to choose

All three are mature SQL databases. The right choice depends on your size, team and how the data is used.

SQLite

An embedded database: a library that stores everything in one file, with no separate server.

• Pros: zero setup and administration, very fast for reads, tiny footprint, easy backups (copy the file), great for apps, tools, tests and small to medium websites. Reads and writes are local function calls, with no network.
• Cons: one writer at a time (WAL mode allows many readers alongside one writer), not meant for many app servers sharing one database over a network, fewer advanced features and no built-in user management.
• Good fit: a content site on one server, mobile and desktop apps, prototypes, edge and embedded use. Many sites with thousands of articles and moderate traffic run happily on it.

PostgreSQL

A powerful, standards-focused open-source server database.

• Pros: rich features (JSONB, full-text search, window functions, CTEs, arrays, extensions such as PostGIS and pgvector, row-level security), strong correctness and transactions, MVCC, good for complex queries and analytics, excellent extensibility.
• Cons: needs a server to run and tune (vacuum, connection limits, upgrades), and more memory per connection (use a pooler).
• Good fit: most serious web apps, SaaS, systems with complex data and queries. A strong default for a new project that outgrows SQLite.

MySQL (and MariaDB)

A very widely used server database, especially in the web and PHP world (WordPress runs on it).

• Pros: very popular with huge hosting and tool support, simple to start, good read performance, mature replication, many managed options.
• Cons: historically fewer advanced SQL features than PostgreSQL (this has improved a lot), differences between storage engines and versions, and some defaults are looser unless strict mode is on.
• Good fit: web apps with simple relational needs, teams that already know it, hosting where it is the standard.

Side by side

	SQLite	PostgreSQL	MySQL
Runs as	library, one file	server	server
Concurrent writes	one at a time	many (MVCC)	many (InnoDB)
Setup effort	none	medium	medium
Advanced features	basic to good	richest	good
Scale across servers	no	read replicas, extensions	replicas, mature
Best for	small/medium sites, apps	most serious apps	classic web apps

How to decide

1. One server, content site or small app? SQLite, with backups.
2. Several app servers, many concurrent writes, or complex data? PostgreSQL.
3. Team or hosting already built around MySQL? MySQL.
4. Unsure and growing? PostgreSQL is the safest long-term default.

Migrating later

Keep SQL standard where you can, use migrations, and avoid database-specific tricks early. Moving from SQLite to PostgreSQL is usually straightforward with a plain schema.

Takeaway: SQLite is excellent until you need many writers or servers, PostgreSQL is the all-round default, and MySQL is a solid choice where it is already the norm.

---

Backend & Database series, Part 2 (performance and operations): 4 of 6. Previous: Database connection pooling: why and how to size it.