Selecting a primary persistence engine is among the most consequential technical decisions in product engineering. Changing databases in a live system with millions of rows is painful, risky, and expensive.
For years, the default advice was simple: use PostgreSQL for complex relations, MySQL for high-velocity reads, and SQLite only for local development or mobile devices. In 2026, advances in storage hardware (NVMe), write-ahead logging (WAL), and distributed replication have upended these historical assumptions.
Detailed Performance and Capability Matrix
+------------------+-------------------+-------------------+--------------------+
| Feature | PostgreSQL 16+ | MySQL 8.4+ | SQLite 3.45+ (WAL) |
+------------------+-------------------+-------------------+--------------------+
| Concurrency | Multi-version MCC | Row-level locking | Single-writer, MVCC|
| JSON Queries | Binary JSONB, GIN | Native JSON Docs | JSON functions |
| Deployment Model | Client-Server | Client-Server | Embedded In-Process|
| Memory Footprint | 64MB - Multiple GB| 128MB - MultipleGB| < 1MB |
| Backup Complexity| pg_dump / WAL-G | Percona XtraBackup| File copy / SQLite3|
+------------------+-------------------+-------------------+--------------------+
When SQLite Excels in Production
Modern SQLite operating in Write-Ahead Log (`WAL2`) mode can easily serve 5,000+ reads per second on modest cloud VMs with zero network round-trip latency. Coupled with tools like Litestream for real-time continuous streaming replication to S3, SQLite is remarkably viable for:
When PostgreSQL Is Inevitable
PostgreSQL remains the undisputed champion when your domain demands:
-- PostgreSQL Native Row-Level Security
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation_policy ON orders
FOR ALL
USING (tenant_id = current_setting('app.current_tenant_id')::uuid);
Conclusion
Do not pick a database based on marketing hype. Align your persistence technology with your query profile, operational expertise, and recovery time objectives (RTO).