The council recommends
On: "Should I use Postgres or SQLite for a small side project with a single writer?"
Top pick
Go with SQLite (in WAL mode)
All three experts agree: for a small side project with a single writer, SQLite is the clear winner. Zero setup, no server to run, no connection pooling or backup infrastructure, and it comfortably handles one writer with many readers. Enable WAL mode, set a busy timeout, and back up by copying the file (or using the .backup command). Keep your schema and queries reasonably standard SQL so a later move to Postgres stays cheap.
Runner-up
Managed Postgres (Neon, Supabase, or similar) — pick this instead if you already know you'll run multiple app instances, need remote/network DB access, or want JSONB indexing and serious full-text search from day one.
Wildcard
A hosted/replicated SQLite layer such as Turso (libSQL) or Litestream for continuous S3 backups — keeps the SQLite simplicity while adding durability and edge/remote access if the project grows.
Best time
Start with SQLite today; don't pre-migrate. Revisit only when a concrete trigger fires: a second app instance, real concurrent writes, remote DB access, or write contention showing up in logs. At that point, a schema migration from SQLite to Postgres is a weekend's work — cheaper than the ops overhead you'd have paid for months.
95%
aligned
All three experts independently recommend SQLite, differing only in the exact triggers that would justify Postgres instead.
Where they agree
✓SQLite is the right default for a small, single-writer side project: zero setup, no server process, no ops burden.
✓Postgres's client-server strengths (high concurrency, network access, multi-instance sharing) are largely wasted at this scale and add unnecessary complexity.
✓SQLite is reliable and fast enough for typical side-project workloads with one writer.
✓Switch to Postgres only when a concrete trigger appears — multiple app instances, remote access, or real concurrent writes.
Where they diverge
↔openai frames the decision purely around deployment topology (multi-instance / network access), while anthropic also weighs feature needs like JSONB indexing and full-text search at scale.
↔anthropic explicitly suggests hosted Postgres (Supabase/Neon) as a ready fallback; openai and google treat Postgres as plain self-managed overhead.
↔google is the most absolute (95) and rules Postgres out entirely for this case; openai and anthropic leave clearer conditional escape hatches.
↔Views on growth planning differ: anthropic advises considering future multi-user production growth now, openai says defer until the requirement is real.
The 3 takes
GPT-5.6 TerraLens · deployment topology
SQLite is the practical default unless you need remote or multi-instance access, serious DBA features, or concurrent writers. Postgres's operational overhead isn't justified here.
90% confident
Claude Sonnet 5Lens · complexity vs. future features
SQLite minimizes complexity so you can focus on the project itself; Postgres only pays off if you need concurrent writers or advanced features. Hosted Postgres (Supabase/Neon) is the natural fallback.
85% confident
Gemini 3.1 Flash LiteLens · deployment simplicity
SQLite's zero-configuration deployment is ideal for a solo single-writer app, and Postgres's client-server benefits would be wasted here.
95% confident
Synthesized from 3 independent expert passes. Treat as informed input, not a guarantee — your own judgment is the final vote.