SQL vs NoSQL
A choice driven by access patterns, consistency requirements and query flexibility — not by data volume, which is the reason usually given.
The framing that actually decides it: do you know your queries in advance?
Relational is the right default. It gives ad-hoc query flexibility, joins, strong transactional guarantees, and mature tooling — and modern managed Postgres scales far further than the folklore suggests. Choose it unless something specific rules it out.
Document, key-value, wide-column and graph stores each buy a specific property at the cost of query flexibility: a key-value store gives predictable single-key latency at any scale, a wide-column store gives write throughput and linear horizontal scaling if you design around the partition key, a graph store makes multi-hop relationship traversal cheap.
The mistake to avoid is choosing NoSQL for "scale" and then querying it relationally — which produces scatter-gather queries, application-side joins, and a system that is both slower and less capable than the relational one you replaced. If the access patterns are not known and stable, the flexibility of SQL is the thing you cannot afford to lose.