I'll just put a few points here to understand when you should use which architecture.<p>NoSQL:<p>- reading is fast, writing is expensive (if all data are pre-processed/denormalized for reading during the writing phase)<p>- often schema-less<p>- low latency (for key-value storage)<p>- offline batch processing (classical Map Reduce)<p>- no ACID, choose 2 of 3 in CAP<p>- demanding on SW engineers to get client-side conflict
resolution, tricky in general<p>- Petabytes of data can be suddenly processed<p>- huge variation of different paradigms, key-value, document, graph, batch etc.<p>- haywire indexing<p>SQL:<p>- writes are fast (normalization), reads are expensive (JOINs)<p>- ACID (well, only to some extent, clustering messes up many ACID properties unfortunately and conflicts arise in corner cases)<p>- set operations and a neat math theory behind them<p>- stable indexing, easily constructable real-time JOINs<p>- OLTP<p>- easier for developers<p>- non-flexible schema<p>- tradition, well-known recipes on how to do things<p>Basically, if you want to have low-latency access, your concurrency model allows eventual consistency, or you have a need to store your data in non-standard structure such as graphs/trees, use NoSQL and pre-process all data to be exactly in the format you require for reading.<p>If you need 99.999% guarantee of consistent data, amount of data you need to handle is under 50TB, you can put your data into a fixed schema and latency doesn't matter that much, use SQL.<p>I would recommend you to ask yourself a question - is your app/business read-heavy or write-heavy and decide accordingly.