Access Pattern Driven Modelling
Designing the data model from the queries the application must serve, rather than from an abstract normalised representation of the entities.
Relational modelling normalises first and queries afterwards; the engine's optimiser and ad-hoc joins make that workable. Most non-relational stores invert this: the model is designed for specific access patterns, and a query that was not planned for is expensive or impossible.
The practical method: enumerate every read and write the application performs, with expected frequency and latency requirements, before choosing keys or structures. In a key-value or document store this determines partition and sort keys, denormalisation, and which secondary indexes exist. Getting it wrong is expensive to correct, because the fix is a migration rather than a new index.
This is why the SQL-versus-NoSQL question is usually asked backwards. The right sequence is: what are the access patterns, what consistency does each need, what is the data volume and shape, and what does the team operate well. The technology follows.
The honest default: relational unless there is a specific reason otherwise. It supports unanticipated queries, enforces integrity, and modern engines handle very large workloads. The specific reasons that justify otherwise are real — extreme write throughput, a genuinely document-shaped or graph-shaped domain, a need for horizontal partitioning beyond a single node's capacity — and none of them are "relational databases do not scale".
Polyglot persistence is legitimate and priced in operational burden per additional store.