If the data has it's own seperate life cycle, idependent of any individual app this is the conclusion i've been heading towards too. when you use an RDBMS the

If the data has it's own seperate life cycle, idependent of any individual app this is the conclusion i've been heading towards too. when you use an RDBMS there's typically a layer of abstraction between the base schema and the domain model (the concepts your application "works with"). it may be nothing more than the queries used to extract data, or it may be a complex set of views and triggers. but deciding whether or not that layer is "a good thing" helps choose between relations and nosql approaches. if your data have their own logic, separate from your application, then this layer helps you match your (often evolving) application to the (frequently more static) data. but if your data are closely tied to your application then it simply "gets in the way". and i agree, too, that data typically do have their "own" logic. on the other hand, i think people could argue that there are cases where one application becomes so large, and so dominant, that it can make sense for that to "drive" the data. which helps explain the idea that nosql and scaling go together (when you really, desperately, need to scale, it could be because one particular thing is so huge that it drives everything else).