This is because you are simply never updating your schema: if you actually want to rename a field, change a datatype, or reorganize your content, you are still going to need to run a migration, and now it won't even be possible to transanction lock the upgrade (better database servers, like PostgreSQL, can do multiple whole-daabase schema modifications within a transaction while still allowing non-conflicting access). In essence, your underlying schema is now "id->blob". ;(
The OP question was "during development". I obviously change the schema in production too: sometimes keeping null-values will work, sometimes a migration will be needed.
My point is that I only do the "production" migration when needed and once per release that requires it, while I can tweak the schema at ease while developing.
If you have a large-enough volume of data, you will meet the situation where just adding a single column takes ages, too.
Adding/deleting/renaming a column is instantaneous as it doesn't involve updating any of the rows on disk: I add columns to tables that have a hundred million rows all the time. (PostgreSQL)
Do a lazy migration--aka, every document gets tagged with current version. The restoration/model routines have a transparent upgrade chain (1->2, 2->3) that move any loaded document up the chain until they reach the current version; then, the app code acts as though all documents are magically updated. If you're worried about performance, have the upgrade chain write out the latest version so it's only upgraded once.
