Choosing a database for your MVP in 2026

Short version: use Postgres. The longer version explains when not to, which is the only part worth reading.

Default: managed Postgres

It is relational when you need it, JSON when you do not, has real full-text search, has extensions for vectors and geo, and every hosting platform offers a managed version. The tooling and hiring pool are unmatched. If you have no strong reason otherwise, stop here.

When SQLite is the better call

• Single-writer workloads, read-heavy.
• Edge or offline-first apps.
• Internal tools where the whole dataset fits comfortably in memory.

SQLite in 2026 with WAL mode and a hosted replication layer is genuinely production-grade for a large class of apps. The catch is concurrent writes and multi-region writes: if either is in your future, do not start here.

When a document store makes sense

Rarely, at MVP stage. If your data is truly schema-less and never joined, a document store saves migration ceremony. In practice most "schema-less" MVP data becomes relational within a year, and you end up doing joins in application code, badly.

The costs you inherit

• Vendor-specific query languages cost you portability. Weigh it honestly.
• Row-level security is a feature, not a substitute for a server-side authorisation layer.
• Serverless connection limits bite at exactly the moment you get traffic. Check pooling before you launch, not after.

The decision, compressed

Relational data, unknown future, small team → managed Postgres.
Read-heavy, single writer, edge → SQLite.
Truly document-shaped, never joined → document store.
Everything else → managed Postgres.

The point is to spend an hour on this and then never think about it again until you have real usage data. The database is almost never what kills an MVP.