I use and like Postgres, but it's crazy to say there's never a scenario where putting data somewhere else makes sense. You just named two examples, Redis and El

I use and like Postgres, but it's crazy to say there's never a scenario where putting data somewhere else makes sense. You just named two examples, Redis and Elasticsearch. It might be fair to say something like: if you have a general purpose OLTP workload with lots of individual reads and writes, with lots of interconnected relationships between models, where you'll need to query and index by lots of different attributes, then you'll probably see as good or better performance with Postgres vs a NoSQL alternative. But there are other uses where you'll have a much easier time using a message queue, a streaming platform like Kafka, flat files in S3, some ingestion system to feed HDFS or Redshift, a sharded key/value store like DynamoDB, etc. I would even go as far as to say, in my own anecdotal experience, for every case where I've seen an app struggling because they're pushing a NoSQL DB beyond its sweet spot, I've seen another app struggling due to pushing Postgres or MySQL. Things like writing all application logs to the primary Postgres DB, or using it as a message queue. To be fair, the catalyst of the problem in these cases is usually the mixed workloads in a single DB instance, and a separate instance of Postgres would work better. But still, other tools that are built for a much more specific purpose can go even further. Plus they can be easier to tune, with Postgres you'll often have to worry about configuration and things like query planner statistics, vacuuming, and XID wraparound.