Postgres is the right answer for 80% of relational use cases — and a surprising fraction of non-relational ones too. JSONB, full-text search, vector search via pgvector, geospatial via PostGIS, time-series via TimescaleDB. The question isn't usually 'why Postgres' but 'is there a specific reason NOT to'.
The sweet spot
Read-write OLTP up to ~1TB and ~10K TPS on a single beefy node. Strong ACID requirements. SQL queries with joins, window functions, CTEs. Acceptable as the only database for a small-to-medium product. Postgres just works.
When it starts struggling
Writes > 50K/sec sustained: vertical scaling hits its ceiling. Datasets > 5TB: vacuum cycles become operational pain. Multi-region active-active: not natively supported (Citus, BDR are extensions but operationally heavy). Heavy analytics: OLAP queries pollute the OLTP cache.
JSONB > MongoDB for most use cases
Postgres JSONB supports full querying, indexing (GIN), and schema flexibility — same operational model as relational, plus ACID. For 90% of 'we need a document store' workloads, JSONB is the better answer than introducing a separate Mongo cluster.
Read scaling
Streaming replication: synchronous (zero data loss, ~10ms write latency penalty) or async (some lag, no penalty). Promote a replica in seconds for HA. Use pgBouncer or PgPool for connection pooling — Postgres itself caps around 1000 connections, pooler raises effective limit to 100K.
Extensions that change the answer
pgvector: full vector DB inside Postgres — eliminates need for Pinecone for <10M vectors. TimescaleDB: time-series compression + continuous aggregates. PostGIS: best-in-class geospatial. Citus: distributed Postgres for sharding. These let one database serve many workloads.