Why SQLite Beats PostgreSQL for Blog CMSes

The wrong mental model

Most developers default to PostgreSQL for anything "serious." It's a reasonable heuristic for multi-service architectures with concurrent writers. But a blog CMS is not that. It's read-heavy (100:1 read/write), single-writer, and the data size fits in RAM for any blog short of the New York Times.

The benchmark nobody runs

We ran PocketBase (SQLite) and a Supabase (PostgreSQL) instance side-by-side on identical Railway containers. For a 500-post blog with full-text search, PocketBase responded in 3ms median. Supabase averaged 18ms. The difference is the network hop: SQLite is embedded in the process, PostgreSQL is a network call.

Backup is a file copy

SQLite's entire database is one file. Backup is cp blog.db blog-$(date +%Y%m%d).db. Restore is pasting it back. No connection pools to drain, no replication lag to account for, no WAL to flush.

The one thing PostgreSQL wins

Concurrent writers at scale. If you're building GitHub, use PostgreSQL. If you're building a blog that gets 100,000 readers a month, you don't need concurrent writers — you need fast reads and operational simplicity. SQLite wins.