Choosing a database when you are not a DBA

The honest default for almost every product is Postgres, and most teams would be better served spending the decision-making energy elsewhere.

The useful discussion is where that default genuinely breaks down.

Why Postgres is the default

• Relational integrity, transactions and constraints — the things that keep data true as a product grows.
• JSON columns when you need flexibility, without giving up the rest.
• Full-text search, geospatial queries and time-series extensions built in or one extension away.
• Ubiquitous hosting, and a hiring pool who already know it.

That combination means a single database handles what would otherwise be three systems, for far longer than people expect.

When a document database fits

When your data genuinely has no stable shape — varying attributes per record, deeply nested structures you always read whole, no meaningful relationships to traverse.

The common mistake is choosing one to avoid writing migrations early on, and discovering later that the schema existed all along, just implicitly and inconsistently across a million documents.

When you need something else alongside

Not instead of. Alongside, for a specific job:

• Redis for caching, sessions and rate limiting — not as a primary store.
• A search engine when Postgres full-text genuinely stops being enough.
• A columnar store for analytics over very large volumes, so reporting stops competing with production traffic.

Each is a second system to operate and keep synchronised. Add them when the pain is real, not in anticipation.

The decisions that matter more than the engine

Backups you have actually restored from, connection pooling sized to your workload, indexes on the columns you query, and migrations that are routine rather than frightening.

A well-run Postgres beats a badly-run anything, and the quality of operation matters considerably more than the choice of engine.

Is Postgres fast enough for a real product?

Almost certainly. A properly indexed Postgres handles tens of thousands of queries per second on modest hardware, and the overwhelming majority of products never approach that. Performance complaints usually trace to a missing index, an N+1 query pattern or an undersized connection pool rather than to the database itself — all of which follow you to any other engine.

Should we use a managed database or run our own?

Managed, unless you have a specific reason not to. Backups, patching, failover and monitoring are the parts that matter and the parts that get neglected when they are somebody's side responsibility. Self-hosting is defensible when cost at your scale is genuinely material or data residency requires it — but budget the operational time honestly, because that is the real price. Our note on what software costs to run covers how to budget that properly.