Typically if you have some polymorphic data attached to some other data, a hybrid approach works. After all, you can't report on what you can't easily quantify

Typically if you have some polymorphic data attached to some other data, a hybrid approach works. After all, you can't report on what you can't easily quantify. My tools elegantly map database fields to my objects; doing this with serialization formats is incredibly crude and brittle. Build tools to do it. A schemaless datastore does not mean a schemaless app. That's actually a problem in most cases. But there are many applications that are better suited to alternatives, especially with large-scale consumer-facing web apps. These threads annoy me; we should all be looking at new tools saying "wow, I wonder what this is good for" rather than smugly burning all the heretics that turn away from to the One True Idol. Certainly that last part is true, but the best uses I have seen, including uses put forth by NoSQL proponents, have been as adjuncts to a relational approach, for example handling data transformation on the way in or out. Otherwise you end up with two fundamental problems: 1) How many other apps can your application support? (see https://news.ycombinator.com/item?id=4495377 https://news.ycombinator.com/item?id=4495377) Where is your public API? Basically you can do this in your db layer and/or your app layer, but you get a lot more flexibility by doing it in the db. With a schemaless app, you can't do it there without intimate knowledge of innards... 2) Strict schemas with validated input and a declarative query language buys you flexible output. Rigid schemas are thus an investment in the future. If your data is sufficiently polymorphic that output can't be flexible no matter how you do it, then I suppose that's not a huge issue. However for many cases where NoSQL is chosen wrongly it is a huge issue.