I use PostgreSQL and change my schema constantly, adding/removing columns, changing data types, switching around foreign key constraints, all within safely guarded transactions that I can roll back if I realize that I'm doing something wrong. (And yes: adding/removing/renaming columns is "instant": it doesn't actually do the work of rewriting existing rows on disk.)

Frankly, I also use MongoDB, and I'm terrified of screwing much with the schema, because then I either a) have to make certain I have anal documentation about what fields are in use on what subsets of objects, keeping code around to make certain to detect and interpret old kinds of data, or b) use "simplified queries" (really, write a bunch of manual code as if I didn't have a query model at all) in order to find and update these old objects, non-atomically and with no transaction safety.

Seriously: the only reason I've so far heard for why having dynamic type verification in my database server is valuable is when you have /so much data/ that it is now fundamentally infeasible to make changes to it with any centralized transaction control--specifically, Google's "it's always the interim somewhere" scenario--not because it is somehow more convenient to do so when you only have in the tens of millions of rows.