Postgres.

Where Postgres fits on a long engagement.

Postgres is usually the correct default, and the strongest argument for it is what it lets you not run. Document storage, search, geospatial queries and vector similarity are all available inside one database with one backup, one set of transactional guarantees and one thing to operate. A second system is a second set of failure modes, and the bar for adding one should be high.

Its known operational edges are worth planning around rather than discovering. Connection handling is per-process and expensive, so a pooler is needed sooner than people expect. Autovacuum needs tuning on high-churn tables or dead tuples accumulate and queries slow for reasons that look inexplicable. Neither is difficult; both are commonly ignored until they become incidents.

What an assigned team does with Postgres.

Database performance degrades with data volume rather than with commits, which is why it surprises teams. A query fine at launch becomes the slowest thing in the system two years later with no change responsible for it.

Watching that trend and acting before it is an incident is standing work rather than reactive work, which is what makes it part of a dedicated development team rather than a call-out.

What we use Postgres for.

• One database instead of four systems JSON, search, geospatial and vectors handled in Postgres, with one backup and one set of guarantees.
• Connection pooling before it is urgent A pooler introduced while it is planning rather than after the connection limit is hit in production.
• Autovacuum tuned for churn High-update tables configured deliberately, so dead tuples do not quietly slow everything.

How Postgres capacity is assigned.

Postgres capacity is assigned under managed data services where the database is the constraint, and inside application capacity where the queries are.