• создание двух баз данных (например, синей и зеленой): каждая версия приложения — синяя (старая) и зеленая (новая) — имеет собственную базу данных. В процессе релиза мы ставим синюю базу данных в режим «только для чтения», выполняем ее резервное копирование, восстанавливаем данные в зеленую базу данных и, наконец, переключаем трафик на зеленую среду. Проблема этой модели в том, что, когда нам необходимо вернуться к синей версии, мы потенциально можем потерять транзакции, если только сначала не перенесем их вручную из зеленой версии;
• отделение изменений базы данных от изменений приложения: вместо того чтобы поддерживать две базы данных, мы отделяем релиз изменений в базе данных от релиза изменений в приложении, сделав две вещи. Во-первых, мы делаем только дополнения к нашей базе данных и никогда не видоизменяем существующие объекты базы данных, во-вторых, мы не делаем никаких предположений в нашем приложении о том, какая версия базы данных будет работать в производстве. Это сильно отличается от традиционного отношения к базам данных, то есть установки на то, чтобы избегать дупликации данных. Процесс отделения изменений базы данных от изменений приложения был использован компанией IMVU (и другими) приблизительно в 2009 г., что позволило ей делать 50 развертываний в день, причем некоторые из них требовали изменения базы данных[96].