Why I Switched from PostgreSQL to SQLite

July 12, 2026 · Architecture

The Database That Surprised Me

For years, I used PostgreSQL for every project by default. It’s powerful, reliable, and battle-tested. But recently, I made a surprising switch — and I’m not going back.

The Realization

Most applications don’t need a client-server database. Here’s what I discovered:

  • My blog gets ~1000 visitors/day. SQLite handles 100x that easily.
  • I’m the only writer. There’s no concurrent write contention.
  • Deployment simplicity matters. One binary, one file, zero configuration.

SQLite’s Hidden Strengths

Performance

For read-heavy workloads, SQLite often outperforms PostgreSQL because there’s no network overhead:

# SQLite: direct function calls
# PostgreSQL: TCP round-trip per query

Zero Administration

No pg_hba.conf, no user management, no VACUUM cron jobs. The database is just a file:

ls -lh blog.db
# -rw-r--r-- 1 kyle staff 2.4M blog.db

Back up the entire database with cp blog.db backup.db. Try doing that with a 50GB PostgreSQL cluster.

Reliability

SQLite is the most tested software component in the world. The test suite has over 100 million lines of test code. It’s used in every iPhone, Android device, and web browser.

When NOT to Use SQLite

SQLite isn’t right for everything:

  1. High write concurrency — SQLite serializes writes
  2. Multiple application servers — you need network access to the DB file
  3. Very large datasets — while SQLite supports terabytes, administrative tools are sparse

My Setup

import "github.com/mattn/go-sqlite3"

db, err := sql.Open("sqlite3", "blog.db?_journal_mode=WAL&_foreign_keys=on")

WAL mode gives me concurrent reads while a write is happening — perfect for a blog where writes are rare and reads are constant.

Conclusion

SQLite is not a toy. For single-server applications, it’s often the right choice. Don’t reach for PostgreSQL just because it’s what you’ve always used. Think about what your application actually needs.

database sqlite