> A database, in most cases, is the business. It's essentially a collection of all the contracts made with customers, and your mode of thinking "I can blow this

> A database, in most cases, is the business. It's essentially a collection of all the contracts made with customers, and your mode of thinking "I can blow this away and start over" that you've learned from all sorts of build tools is completely contrary to that. Thanks for this metaphor. One of the other big benefits to a database-first design is that as your business becomes more complex, there will inevitably be other applications querying the database. If you don't model your constraints in the database you'll end up with a microservices architecture where everything has to call through facades to talk to the database. If you model your constraints correctly in the database, it's much easier to open access to the data to other applications. The idea of code generating the database schema seems absurd because in all but the first steps of a greenfield app, the code is clueless about what the data means. It's the database's job. One reason I think we are seeing a renaissance of database level access control is the popularity of connecting mobile applications and web clients directly to the database. Even if you don't think it's a good practice, the pressure mobile and single-page-app developers are putting on APIs like Firebase, Cloudant, and my employer FaunaDB to offer rich access control features means developers have more options. Here is a write up about how FaunaDB's security features can be used for common app paradigms. By using the database's security features, you can model things like user consent that are relevant for GDPR. https://blog.fauna.com/data-security-in-the-age-of-cloud-native-apps https://blog.fauna.com/data-security-in-the-age-of-cloud-nat... My point being that if you let the database, not the code, be the source of truth, the benefits multiply.