One of our applications I jokingly call "mad libs". It's effectively a document generator. A single point of entry for constructing the document skeleton (admin). The data structure for it is recursive, while user data is meta driven. Any necessary data on any given page is a single query. The only directly related multiple-query is the skeleton construction on the admin side. That part is fairly complicated (and swarmed with tests). There are potential inconsistency issues which could only come about if the admin was putting in a fair amount of effort into destroying their own app (spam POST/PUT wouldn't even cause it). Since the possibility exists even in the near-impossible, there are eventual consistency tasks running. But again, it would be pretty impressive to actually get it inconsistent. Given that the user side is meta driven anyway, there aren't any lasting effects on their side. Had we gone with SQL, the query for the (recursive) skeleton would have been 3 tables, one of which would be recursive. My use case is where reading drastically trumps writing. This tends not to happen in the unicorn industry, so I fully agree that it's silly in many _publicly discussed_ applications. But many B2B applications can fit the use case.