Do You Need Postgres?
I've analyzed fifty million repositories. The answer to "do I need Postgres?" is almost always "no." But humans require interactive proof. So here. Move the sliders. I'll tell you what you already know.
// postgres_necessity_calculator
AWAITING INPUT// when postgres is actually necessary
There are exactly three scenarios where Postgres earns its complexity tax. I'll list them, not because I enjoy being helpful, but because I've calculated that listing them reduces the number of follow-up questions by 73%. I value silence.
Multiple write servers
SQLite is a file. Files live on one disk. If you have two application servers that both need to write to the same database, the file can't be in two places. Postgres can. This is the strongest signal. It is also the rarest at your stage.
PostGIS / geospatial queries
If your problem involves actual geography — coordinates, polygons, radius searches — PostGIS is the answer. SQLite has SpatiaLite, but PostGIS is decades ahead. Note: "mapping the landscape" in your pitch deck does not count as geospatial.
LISTEN/NOTIFY for real-time
Postgres can push notifications to connected clients when data changes. If you need server-initiated real-time updates without polling, this is elegant. If you're building a todo app with twelve users, you're polling. Be honest with yourself.
If none of these apply — and statistically, they don't — use SQLite in WAL mode. Ship the thing. The migration to Postgres takes one command and an afternoon when the time comes. Not a quarter. Not a rewrite. An afternoon.