Hello, Rikomer, you wrote: R> we Imagine an update of a software of atomic station or other software 24/7 which it is impossible to stop. If atomic station there critical a software such that it or is possible on the move, or it is not necessary to update between operation cycles at all. And the planned stop of times in couple of years is quite admissible. And noncritical let to itself though every night . R> As there an update if it is necessary to update for example a software + basis. R> from a software I still can understand that by turns we update , computers. Or the software allows to be updated on the move. It allow, for example: Erlang (there is a complete set of regular mechanisms of such update), Python (functions and declarations of classes are updated at once, for objects on these classes there are some decisions of a different level ), Java (an overload of classes with recovery from ), many other things... R> And here with basis not clearly. If the structure changes so, what the old version of application cannot work with new as do? That is simple so do not do there should be a compatibility on road even if the plan of passage demands the several artful intermediate stages and operation rise in price at passage (how to update some versions of columns simultaneously). R> a variant at me, but all the same difficult R> 1. We do a cluster of bases and replication between bases. R> 2. We chop off a little from a cluster, we roll on all of them changes R> 3. We include the new version of basis, we chop off old versions and further it is rolled R> 4. We roll on new versions of basis a script on data migration which happened on the old version of basis while did point 2 All the same there will be not consistent intermediate states. It is necessary to do without such .