Database Choices: When Postgres Is Enough (Almost Always)

Database choice is one of the few decisions in a stack conversation where founders come in with a strong opinion already formed, usually "we need something that scales like the big tech companies." In practice, a well-indexed PostgreSQL database handles the overwhelming majority of applications we build, comfortably, for years, and switching to something more exotic usually solves a problem the project doesn't have yet.

Why we default to Postgres

• It's relational, which matches how most business data actually looks — customers, orders, and the relationships between them.
• It supports JSON columns natively now, which covers most of the flexibility people reach for a NoSQL database for.
• The tooling, hosting options, and hiring pool are all mature, which matters the same way it does in choosing any part of a tech stack.
• It scales further than most projects will ever need before a genuine architectural rethink becomes worthwhile.

When something else actually makes sense

Specific access patterns — a graph of deeply interconnected relationships, or a write-heavy time-series workload — can genuinely benefit from a purpose-built database. That's a decision made after profiling a real bottleneck, not before writing the first query.

The database that scales best is the one your team already knows how to operate well under pressure at 2am.

If you're being pitched a more exotic database before anyone's measured an actual bottleneck, that's worth questioning. Most performance problems we've diagnosed in production Next.js apps turned out to be missing indexes and inefficient queries, not the wrong database engine.