everyone gangsta until they have to feature flag a database schema change
Everything I've worked on in the last few years would have been in far, far better shape if they had just started with a no-schema data management system like Bigtable and just adapted their backend code around its limitations.
Imagining you are safe because you are smoke-checking DML statements in staging is just begging for a week-long outage.
Heck, I don't need to imagine, I have seen it time and time again.
After you’re onboard with this philosophy then I’m ready to sell you the fact that you don’t need joins, indexes, or transactions. If a giant complicated service like gmail doesn’t need any of those things then very likely that your thing doesn’t need them either.
second: even if you don't have an explicit schema in the database, you still have to have a way to know which data goes in which column. just because it isn't written in a definition language doesn't mean the concept doesn't exist and doesn't require to be maintained as the application domain evolves.
The last time I tried a project with a no-schema DB, it was a huge PITA. It sucks having a function fail on one single document because it had a number instead of a string. I love flexibility, but it is very valuable to have the right constraints in the right places. I quickly learned that a schema is just that.
By "typed language" I suppose you mean "statically typed language". This isn't relevant because A) JSON types exist and B) I've never had a problem with unexpected types from user data in a dynamic language, not even in PHP.
> Otherwise, how is this not caught when it enters your system?
It should be caught, and it's very important that it be caught all of the time and not have any issues due to bugs or version mismatches. That's why the schema should live in the DB.
YMMV I guess.