It's really "not" that complicated. Start by assuming by default that you will use an RDBMS, then: 1) Attempt to model a database schema that fully and complet

It's really "not" that complicated. Start by assuming by default that you will use an RDBMS, then: 1) Attempt to model a database schema that fully and completely supports said data. This will force you to get a sufficiently deep understanding of the domain problem and how it's different parts relate to one another. 2) Is there a part of the domain problem whose dynamic or unstructured nature cannot be properly represented on a fixed database schema and/or this unstructured piece of data must be performantly queried? Add a "companion" Document DB to your architecture. 3) Are there performance issues/requirements on a given part of your system and you need to hold volatile data such as a cache of processed data, or you need to efficiently handle user sessions across multiple machines, or even a queuing system for processing tremendous amounts of data coming in? The add a "companion" Key-Value DB to your architecture. ... And many, many other examples of other specialized NoSQL DBs could be added here, but you get the idea. Summing up: Understand the data > Attempt to model an RDBMS schema that supports said data > Use proper "companion" DBs for whatever data that does not fit in a RDBMS.