On Tue, Dec 19, 2017 at 8:24 PM Brian Towles <btowles(a)cloudera.com&gt; wrote: It depends on what schema changes have occurred between the versions. We review the liquibase change files as part of version upgrades to determine if the changes are breaking or not. For some, the schema changes have been very small and non-breaking, such that you have (old) instances running, you start new instances with a new version, the first of which does the schema migration, they join the infinispan cluster, and then stop the old instances. When the changes are not compatible, we do stop the old instances, then start the new instances, and take a few minutes of scheduled downtime. We can get it to 5-10 minutes of downtime with our current AWS ElasticBeanstock deployment methods, which for us is "good enough" at the moment. It'd be ideal if schema changes could be spaced out stepwise through versions so to be fewer breaking changes. Some (:cough: v3.2.0 changing a primary key definition on offline_client_session) we have to catch in a pre-production staging environment. We test the upgrade against a clone of the database, to find (and purge) data that would cause an upgrade failure, even allowing for downtime. Thanks, Matt -- Matt Domsch Executive Director & Senior Distinguished Engineer Quest | Engineering Matt.Domsch(a)quest.com