Postgres is almost always the right answer. Here's when it isn't.

Why the default matters

The database is the one decision in a stack you don't quietly swap later. The framework can be replaced page by page. The hosting can move in a weekend. The data layer is where the weight lives — schemas, queries, migrations, the way your team thinks about state. Picking it well on day one buys you years of not thinking about it again.

Postgres is the boring choice. It's also the choice we've shipped on every B2B product, every internal tool, and every consumer app we've built in the last three years. The 'is it still the right pick in 2026' question gets asked a lot. It is.

What Postgres quietly gives you

• Real transactions — not 'eventually consistent' fan fiction
• JSONB — most of the time you don't actually need a separate document store
• Full-text search — good enough that you can skip Elasticsearch for v1
• Vector search (pgvector) — the reason most of our AI features don't need a second database
• Foreign keys and constraints — the cheapest bug prevention you can buy

Every one of those features is a database you didn't have to add. The total operational savings — fewer services to monitor, fewer connections to pool, fewer migrations to coordinate — is the kind of thing nobody writes a blog post about because it's invisible. It's also the biggest single reason our small teams ship faster than larger ones.

Where we reach for something else

Three cases, in our experience:

• Truly time-series data at scale — a metrics product writing a million points a minute should look at TimescaleDB or ClickHouse. A SaaS dashboard tracking events for ten thousand users should not.
• Graph queries that are the product — fraud rings, social graphs, recommendation engines where the query *is* the traversal. Neo4j earns its keep. A 'we have users and they have friends' app does not need a graph database.
• Heavy analytical workloads on top of operational data — at that point you usually want a warehouse (BigQuery, Snowflake, DuckDB) alongside Postgres, not instead of it.

What we don't reach for

MongoDB, as a first database, in 2026. It's a fine product for specific shapes of work. 'My startup might need to scale' is not one of those shapes. We've inherited four MongoDB projects in the last two years and migrated three of them to Postgres before they hit ten thousand users — the schemas were already begging for relations the team had spent a year working around.

A managed key-value store as the primary database. Redis is wonderful as a cache, a queue, a rate limiter, a session store. It is not the source of truth for your users table. You will regret that one specifically.

Whatever the cloud provider is pushing this quarter. AWS, Google, and Azure each have a proprietary database they would love you to marry. The lock-in cost shows up the day you want to leave, not the day you sign up.

The hosted-Postgres question

For most projects we default to a managed Postgres — Supabase, Neon, or RDS depending on what the rest of the stack looks like. The arguments for self-hosting it on a single VM are usually nostalgia. The five hours a month you spend on backups and patching are worth more than what the managed bill costs.

The only time we run our own Postgres is when there's a specific compliance constraint, or when the client already has a DBA on staff who knows what they're doing. Those teams don't need our opinion anyway.

The lesson

Database choice is one of those decisions where 'boring' is doing a lot of quiet work. Every hour you don't spend re-evaluating the data layer is an hour you spend on the product. Pick Postgres, write the schema carefully, and put the energy that would have gone into the framework war into shipping something users want.

If three years from now you have a problem Postgres genuinely can't handle, that's a great problem to have — and a much easier one to solve than the alternative of spending the first year of your product picking the perfect database.