[mbreese]

Oh no! Someone needs to model their data before writing code??? The horror!

You're going to pay for getting the data model right eventually. The only question is - do you want to pay for it now or later? If you push it off until later, it's generally more painful to make changes. Or, you have to maintain a sub-optimal model for as long as the application exists.

[threeseed]

I take it you must be new to software development.

Because I have never seen or heard of a situation where the data model has been designed upfront and never changed along the way. And you seem to be turning this into a black/white scenario. In almost all cases you do your best effort upfront and then iterate.

The advantages of these NoSQL/Schemaless style databases is that you can do this migration in your app instead of in your app+database. And unfortunately schema/data migration tools for databases really aren't that great - even after all these decades.

[pjlegato]

The disadvantage of NoSQL is that you do the migration in your app rather than in your database. This requires all programs that touch the database to know about every historic migration that ever happened, since there is still data in the database that uses the old schema.

With a SQL database, there is one source of truth: the current schema. It is not necessary to maintain historic information about all previous versions of the schema in every program that uses the database; they only have to know about the current version.

[mbreese]

One problem with these schema-less style databases is that you still actually have a schema. You just don't have a good reference for what it is anymore since it's trapped in your code, likely in multiple files.

[CuriouslyC]

It is short-sighted to load everything in the application, because at best utilizing the data in another context is going to involve a major (possibly painful) code refactor. You are more tightly coupling your data to your application stack, which isn't the best idea in my experience.

As an aside, Postgres supports multiple schemas for a given database, so it is trivial to support multiple versions of a single table, provide legacy support via views, etc.