Engineering - 6 min read
A small defence of Postgres for tiny apps
By Hana Nguyen - 6 May 2026 - 1 views
Photo: Caspar Camille Rubin on Unsplash
SQLite is wonderful. So is Postgres. Here is when the extra moving part is worth it for a side project that could grow up.
The default answer for a tiny app is SQLite. Single file, fast, no servers, fine for almost everything. The default answer is right far more often than developers will admit.
But there is a class of side project where Postgres is worth the slightly grown-up setup. The signal, for me, is when I find myself wanting one of three things: real concurrency, real full-text search, or row-level locking that doesn't make me sweat.
The other thing Postgres gives you is permission to be a bit ambitious. JSON columns, generated columns, partial indexes, listen/notify, materialised views. Most of these you will not need. Some of them you will need exactly once, and then they will pay for themselves three times over.
The cost is one more thing to back up, one more password to manage, and a slightly slower local boot. Worth it, I think, the moment you start wanting your data to outlive the laptop it lives on.
But there is a class of side project where Postgres is worth the slightly grown-up setup. The signal, for me, is when I find myself wanting one of three things: real concurrency, real full-text search, or row-level locking that doesn't make me sweat.
The other thing Postgres gives you is permission to be a bit ambitious. JSON columns, generated columns, partial indexes, listen/notify, materialised views. Most of these you will not need. Some of them you will need exactly once, and then they will pay for themselves three times over.
The cost is one more thing to back up, one more password to manage, and a slightly slower local boot. Worth it, I think, the moment you start wanting your data to outlive the laptop it lives on.
