>If you're creating a MongoDB table with a user JSON object, and then you just let different services manipulate that JSON however they want then your data will

>If you're creating a MongoDB table with a user JSON object, and then you just let different services manipulate that JSON however they want then your data will screw up in the future. There needs to be a robust contract between the app code and the data store that defines what the data is allowed to look like. That's where the time gets spent, whether it's in the database admin or in the application layer. If other app touches my database in write mode and modifies the structure by mistake, then it is relatively good scenerio because the problem is easy to notice In compare to messing with data e.g account balance += 200 And relational db without some hardcore constrains / triggers do not check it I'd still rather have that code in app >My point is that the development speed for nosql should be roughly the same as for relational databases, because you should be spending the same amount of time thinking about your data. The database you use is almost incidental. Whether you choose to create a users table in Postgres and make sure the data is valid there or whether you choose to create a JSON object in MongoDB and make sure the data is valid in the application logic doesn't matter - the hard, and the bit you should be spending time thinking about what does 'correct' mean for this set of data. Thats in theory In practice it always took me more time to setup postgre mssql and initial system model Than when using mongo Ive always used relational dbs but Ive started wondering whether I should start using nosqls in real world scenerios