What they're testing
Whether you argue from access patterns, and whether you're willing to say "at our scale Postgres is enough".
The short answer~30 seconds
I choose on query shape, not on scale. If data is always read by exactly one key and never joined, a key-value or document store fits better. If you need ad-hoc queries, constraints and multi-table transactions, Postgres wins, and it takes far more traffic than people assume. The threshold that actually bites is rarely "the data is too big" — it's "writes exceed what one node can take".
The long answer
The point worth making is that most systems never reach that threshold. A mid-sized Postgres node handles thousands of transactions per second and terabytes of data; if you choose Cassandra before measuring because "we'll be big later", you're paying up front in modelling rigidity for something you may never need. It's among the hardest architectural decisions to reverse, which is a reason to defer it.
When NoSQL genuinely fits, the reason is usually very specific. Cassandra when you need extreme write rates and accept queries only by a pre-decided partition key. Redis when access is hot key-value and losing data is survivable. Elasticsearch when the problem is full-text search and relevance ranking. MongoDB when documents really are heterogeneous and you read whole aggregates. Each trades one specific thing for another.
What candidates routinely miss: Postgres has absorbed most of those cases. jsonb with a GIN index gives you a document store with transactions; pg_trgm and full-text cover fuzzy search at moderate scale; LISTEN/NOTIFY plus SKIP LOCKED makes a decent queue. Saying so shows you're judging the tool by what it does now, not by a 2014 comparison table.
What they'll ask next
?So when does Postgres genuinely run out?
When WRITE volume exceeds one node and you can't shard along a business boundary; when you need low-latency multi-region writes; or when the model genuinely is large-scale time series or graph. Reads scale out with replicas far more easily than writes do.
?What about using both?
Very common and reasonable — Postgres as the source of truth, Redis as cache, Elasticsearch for search. The price is keeping them in step, and that's where bugs live: they diverge when one write succeeds and the other doesn't. The outbox pattern is the usual remedy.
These lose points
- "NoSQL scales better" as a blanket claim. Scales what? Reads, writes or storage — three different things that scale three different ways.
- "Schemaless means faster development". The schema still exists; it just moved into application code where nothing validates it.
Sources
- PostgreSQL — JSON Types and GIN indexing for `jsonb`
- Martin Kleppmann, Designing Data-Intensive Applications, ch. 2 — data models follow access patterns