Very well put. It is not access type (direct vs indirect) that make schema improvements hard, but access preservation: availability. And indeed copying the data

Very well put. It is not access type (direct vs indirect) that make schema improvements hard, but access preservation: availability. And indeed copying the data often leads to one or more of the copies being wrong, unless special measures are taken in that direction. > How do you guarantee that all of the apps that touch that data use the current version of said code? An approach that may be worth considering is to not require all apps to use the current version: allow multiple versions. For some cases this would work, say if the semantics of the newer version are backwards compatible with the semantics of the older version. If the data semantics are preservable, transforming a schema could happen while each data access request to the schema is actively transformed. But it clearly wouldn't work in all cases. More work to handle that would be needed. > Code normalization is as important as data normalization. True, this is the near show-stopper really. In that case, the best one can hope for is preparing the state of the new version (new data in new schema) and carefully coordinating a quick restart of the old version for the new version. I would love to hear your thoughts on this. We have been working towards that direction with ChronicDB (http://chronicdb.com http://chronicdb.com) and would welcome feedback.