> What you gain from not having to worry about modifying schemas and enforcing referential integrity, you lose from having to add more code to your app to check that a DB document has a certain value.

This × 100. The app I'm working on has so many `if model.value` calls scattered throughout the code that it becomes difficult to follow and make sure no spots were missed. Simply adding validation to the app before writing data isn't sufficient since there are other ways to persist data and NoSQL provides no sense of data integrity.

> In essence you are moving responsibility for data integrity away from the DB and in to your app, something I think is quite dangerous.

This is only necessarily true of specific "instances" of NoSQL. MongoDB has supported server-side schema enforcement since Dec 2015, for example. Most likely other relatively mature NoSQL systems have similar features. There's certainly nothing about NoSQL which makes server-side schemas impossible.

The issue is social, not technical. I believe that people that want to use NoSQL dislike schemas - or believe that their use case is too hard to describe with a schema. Most NoSQL databases won't have schema validation set up even if the feature is available.

Database modeling should be the foundation of any non-trivial application. With a proper data model, there are ways to reason about the data and hence the application as well. Also, with the advent of new client-server communication like GraphQL and Hasura, the frontend developer needs to rely on schema specifications for designing the applications.

> In essence you are moving responsibility for data integrity away from the DB and in to your app, something I think is quite dangerous.

Why is this a bad thing? The code in my app can be tested and is much more expressive than some contraints in the DB.

The problem there is what if you have two different apps connecting to the same DB. When the DB enforces referential integrity both apps can be certain the data in the DB is correct and they wont be able to mess with it. When the apps have to take on that role each app must implement (i.e. unnecessarily duplicate) the same integrity checking functionality. In a complex environment where you might have different apps using the same NoSQL data store that becomes very difficult to manage.

Even if your app is the only app accessing the database, the code in your app can be changed. When you change the validation criteria, do you reread every row from the database and revalidate it?

When validation criteria are changed on an SQL server, it revalidates all the rows - either immediately, or at the end of the transaction. With the DB doing the validation, the default is that all rows are valid.

Also, do you ever side-step your database abstraction layer to send SQL directly? If you ever insert/update/delete rows that way, perhaps for performance reasons, now you have an extra place in your app to make sure the relevant validations are kept up-to-date.

https://robots.thoughtbot.com/validation-database-constraint...

Relatedly, this article suggests that your app should only be validating user input - so there should be no app validation of fields not set by end users - whilst the database itself should validate what your app gives it.