Postgres vs SQLite vs MongoDB

Best for Almost any real app you plan to keep. The correct default for a SaaS, a marketplace, an internal tool, anything with users, money, or relationships between things.

Strengths

• Relational correctness with real transactions and constraints, so your data stays consistent even under concurrent writes — the thing you cannot bolt on later.
• It's also a great document store: native JSONB with indexing means you get 'schemaless when you want it' without leaving Postgres.
• The ecosystem is unmatched for vibe coders — Supabase and Neon give you a production Postgres in two minutes, and Drizzle/Prisma target it first-class.
• Extensions (pgvector for AI embeddings, PostGIS for geo, full-text search built in) mean one database does the job of five.

Watch out

• It's a server: you provision it, connection-pool it, and pay for it even at zero traffic (though free tiers on Neon/Supabase cover hobby projects).
• Connection limits bite serverless deploys hard — use a pooler (Supabase's, Neon's, or PgBouncer) or you'll hit 'too many connections' the moment you get traffic.
• More power means more footguns: migrations, roles, and vacuum tuning exist and you'll eventually meet them.

Best for Local-first apps, CLIs, desktop/mobile apps, prototypes, and edge deploys where the database is a file that ships with the code. Increasingly viable for small-to-mid production sites via Turso/libSQL.

Strengths

• Zero setup, zero server, zero network hop — it's a single file, so reads are absurdly fast and there's nothing to provision or pay for idle.
• Rock-solid and battle-tested: it's the most deployed database on earth (every phone, browser, and app). It will not surprise you.
• Perfect for tests and dev — spin up a throwaway in-memory DB per test run instead of mocking a database.
• Turso/libSQL and Cloudflare D1 have made 'SQLite at the edge' a real 2026 pattern, replicating the file close to users.

Watch out

• Writes serialize — one writer at a time. Fine for read-heavy apps, a wall for write-heavy multi-tenant SaaS.
• It's file-local by default, which fights serverless/multi-instance deploys — you need Turso/D1 or a single-node host (Fly.io, a VPS) to make it work.
• Weaker typing and thinner concurrency/tooling than Postgres; you'll outgrow it if the app becomes genuinely multi-user and write-busy.

Best for Genuinely document-shaped, schema-fluid data — event logs, content/CMS blobs, product catalogs with wildly varying fields — and teams that want to move fast before the schema settles.

Strengths

• Store nested JSON documents directly; no joins, no migrations to add a field. Iteration speed is real when your shape keeps changing.
• Horizontal sharding is a first-class, well-worn path, so scaling out huge write volumes is a solved problem here.
• Atlas is a polished managed service with a generous free tier, and the Node/TypeScript driver experience is smooth.
• Flexible schema genuinely helps early-stage products where you don't yet know your data model.

Watch out

• Most apps that reach for 'schemaless' actually have relational data, and you'll reinvent joins in application code and hand-maintain consistency — badly.
• No enforced schema by default means data drift: years of documents with subtly different shapes, and no constraint stopped it.
• For the vibe-coder default stack (Next.js + an ORM), Postgres has more gravity, better AI-tool support, and fewer 'why is my data inconsistent' surprises.