reality is 99% of companies out there will be just fine with a single db server
all this nosql fad is simply because SQL is hard and newbies would just rather call it old and slow because they can't be bothered to learn it
all this nosql fad is simply because SQL is hard and newbies would just rather call it old and slow because they can't be bothered to learn it
As such it makes starting really easy which is the allure. Many seem to hope they can avoid doing schemas and well architected data. Or push it in to the future. The rude awakening comes when you do need to run complex queries (and you do not have SQL or joins at all). Or when the people do not understand they have to take care about data integrity in app layer now.
At the end people going for NoSQL have a much harder to manage system without the tools (like SQL, schemas, constraints)
I think NoSQL is great for very specific purposes. Caches, keeping state, logging stuff. For many things it is misused and postgre with jsonb can do everything you need (faster, easier) without rude awakenings.
What most companies can do well with is a single master DB which handles updates.
(Some companies can't, though; e.g. GrubHub switched to Cassandra because no monolithic RDBMS could handle the write load.)
Also: Designing a system that is prepared for unknown unknowns is practically impossible. Initial design is not too bad, but the continuous adjustments kinda suck.
If you want CP or AP, then you need a "fad" database.
Also, no you don't. It's possible to have distributed RDBMS.