blog

Инструменты миграции схемы БД: как выбрать?

NEXTREE.

08 7월 2026 • 11 min read

Сравнили Flyway, Liquibase, Bytebase и Atlas в среде MSA·DDD и разобрали, что выбрать в зависимости от ситуации.

1. Схема меняется без остановки

В DDD, MSA и облачной нативной среде схема базы данных не является фиксированным активом. Она продолжает меняться на протяжении всего времени работы сервиса.

Причина в домене. Сущности и агрегаты изменяются по мере углубления понимания домена. Атрибуты добавляются, одно целое делится на две части, значения, бывшие колонками, поднимаются в отдельные таблицы.Когда модель эволюционирует, схема тоже эволюционирует.

Если делать это вручную без инструментов,ALTERесли просто запускать, то схема в разных средах может расхождаться. Инструменты миграции управляют изменениями в виде версий, гарантируя, что в любой среде они достигают одного и того же состояния в одном и том же порядке.

MSA добавляет сюда дистрибуцию. Каждый сервис имеет свою собственную БД.Database per Serviceв этом случае миграция также происходит на уровне сервиса. Здесь нужно контролировать ситуации, когда несколько сервисов меняют схему с разной скоростью, а не сбрасывать DDL централизованно раз и навсегда. Если требуется безостановочное развертывание, то "заблокировать таблицу и немного приостановить, чтобы изменить" не получится.

Перед выбором инструмента: два подхода

Метод	Описание	Представляемые инструменты
Изменение (Migration) основано на	процедура изменения схемыV1, V2, V3накоплены. Накопление изменений означает текущее состояние.	Flyway, Liquibase
основано на состоянии (декларативное)	если задать целевую схему, инструмент вычислит разницу с текущей и создаст скрипт.	Atlas

основывается на изменениях,интуиция ясна и легко отслеживается, декларативное основаниеУправление версиями аккуратное и удобно для автоматизации.Эта разница является отправной точкой для выбора инструмента.

2. Четыре инструмента, на первый взгляд

Flyway — самый простой и самый широко используемый

SQL-файлы, такие как V1__create_member.sql, применяются в порядке с приложенными версиями и описаниями. Поскольку написанный SQL выполняется целиком, предсказать, что произойдет, легко, и благодаря бесшовной интеграции со Spring Boot часто используется автоматический режим применения при запуске. Однако автоматическое откатывание и сравнение схем относятся к коммерческой области.

-- V2__add_email_to_member.sql 
ALTER TABLE member
   ADD COLUMN email VARCHAR(255) NOT NULL DEFAULT '';

CREATE INDEX idx_member_email ON member (email);

Написанный SQL применяется без изменений,flyway migrateодного раза достаточно.

Liquibase — абстракция и откат, подтверждения нормативов

XML·YAML·JSON·SQLописания измененийдля документирования изменений. Благодаря абстракции, не привязанной к типу БД,поддерживаются несколько СУБДилиуправление откатами явно.Это удобно во время выполнения. Liquibase Secure часто выбирается в строгих условиях, поскольку сопоставляет проверки политик и доказательства изменений и отката с такими стандартами, как SOX, PCI DSS и DORA.

# db/changelog/002-add-email.yaml
databaseChangeLog:
  - changeSet:
      id: 002-add-email
      author: dev
      changes:
        - addColumn:
            tableName: member
            columns:
              - column: { name: email, type: varchar(255) }
      rollback:
        - dropColumn:
            tableName: member
            columnName: email

Если явно указать блок rollback, команда liquibase rollback вернёт изменения обратно. Простые изменения, как указано выше, могут быть опущены, и автоматическое создание обратных операций происходит. Хотя выразительность хороша, порог входа немного выше, чем у Flyway, где пишется SQL напрямую.

Обзор аббревиатур нормативных актов

- SOX(Закон Сарбейнса–Оксли) — нормативное регулирование бухгалтерского учёта и внутреннего контроля для публичных компаний в США. Требует контроля и доказательства изменений финансовых данных.

- PCI DSS — стандарт безопасности данных платежных карт. Требует контроля изменений и журналов аудита.

- DORA(Закон о цифровой операционной устойчивости) — нормативное регулирование операционной устойчивости финансовых учреждений ЕС. Требует доказательства истории изменений и возможности отката.

Bytebase — платформа для DevOps баз данных

Если первые две являются библиотеками и CLI, то Bytebase это платформаЭто поток изменений: запрос на изменение → обзор → одобрение → применение в веб GUI, управляемый на одном месте правилами обзора SQL, историей изменений и контролем доступа. Несколько команд управляют несколькими БД.Государственное управление и отслеживание аудитаЭто подходит для этой важной организации. Однако внедрение является тяжелым.

Atlas — декларативный + GitOps

Если вы укажете желаемую схему с помощью HCL·SQL·ORM, то текущий статус и разницу автоматически рассчитают,создавая миграцию. Схема объявляется кодом и управляется в Git,что является сильным преимуществом GitOps.Если вы не знакомы с декларативным подходом, вам потребуется сменить образ мышления.

# schema.hcl — "최종 상태"를 선언한다
table "member" {
  schema = schema.public
  column "id" { type = bigint }
  column "email" { type = varchar(255) }
  primary_key { columns = [column.id] }
}

Добавьте колонку email в декларацию и выполните atlas schema apply, и Atlas вычислит и применит ADD COLUMN, сравнив с текущей БД.

Таблица сравнения

Элемент	Flyway	Liquibase	Bytebase	Атлас
Подход	Основанный на изменениях	Основанный на изменениях	Основанный на изменениях + платформа	Декларативный центр
Формат написания	SQL	XML/YAML/JSON/SQL	SQL(+GUI)	HCL/SQL/ORM
Поддерживаемые СУБД	30+	60+ (кросс DB)	25 движков	Основная открытая RDBMS
Откат	Ручной (автоматический — коммерческий)	Множество автоматических·сырой SQL указано	Поддержка	План·откат
Автоматический дифф	Нет	Часть	Часть	Сила
Рецензия·одобрение	Внешний CI	Внешний CI	Встроенный (GUI)	CI интеграция
доказательства аудита	ограниченный	SOX/PCI/DORA в Secure	журнал изменений·одобрений	план·история изменений
лицензия	OSS + коммерческий	OSS + Pro·Secure	OSS + Enterprise	OSS + Pro
подходящая ситуация	простой·дружественный к SQL	мульти БД·откат·регулирование	управление командой	Декларативный·GitOps

Портируемостьдаже так же важны, как и количество DBMS. PostgreSQL·MySQL·Oracle·MS-SQL имеют разные синтаксисы DDL для одних и тех же изменений, поэтому Flyway требует ручной обработки различий между продуктами. Liquibase создает соответствующий SQL для целевой DBMS на основе абстрактного changelog.Поддержка нескольких продуктов с одной декларациейэто просто. Если у клиентов разные DBMS, это различие может стать решающим фактором.

3. Как использовать - действия с помощью Flyway и GitOps

Файл миграции просто должен соответствовать правилам именования.

db/migration/
├── V1__create_member.sql
├── V2__add_email_to_member.sql
└── V3__create_post.sql

Формат V{версия}__{описание}.sql, и он применяется только один раз в порядке версий. Четыре команды используются чаще всего.

• migrate — последовательно выполнять еще не примененные миграции

• info — отобразить историю применения и ожидающие изменения

• validate — проверьте контрольную сумму, чтобы убедиться, что примененный файл не был изменен

• baseline — установите базовую точку при первой интеграции в работающую БД

validate предотвращает ошибки чаще, чем вы думаете. Если кто-то изменит уже примененный файл, миграция остановится из-за несоответствия контрольной суммы. Принцип один.Не модифицируйте примененные миграции, добавляйте новую версию.

Миграция может быть расположена в любом модуле

Если вы разделили один сервис на несколько модулей Gradle, таких как домен и загрузка, то миграция будет происходить в модуле загрузки (приложения).

member-service/
├── member-domain/ ← 엔티티·도메인 로직
└── member-boot/ ← 애플리케이션 부트·설정
└── src/main/resources/db/migration/ ← Flyway 마이그레이션

Если есть несколько сервисов и хранилища разделены, то каждый сервис следует одной и той же модели в своем хранилище, и каждый модуль загрузки владеет миграцией своей БД (Database per Service).

Реалистичный CI/CD пайплайн

В облачно-ориентированных архитектурах Git как единственный источник правды (SSOT)GitOps — стандарт. Сводится к "При отправке PR применяется CD", но фактический процесс в enterprise гораздо сложнее.

• Управление версиями + обзор — все изменения, включая таблицы, индексы и исходные данные, загружаются как PR для обзора.

• Автоматическая проверка — в CI применяется к временной базе данных для проверки синтаксиса, ограничений и индексов, удаляющие команды (например, без условий DROP и т.д.) блокируются статическими проверками. Исполнительная учетная запись имеет минимальные права.

• Тестирование воспроизведения в нижних средах — после применения на стейджинге проводятся модульное, интеграционное, регрессионное и нагрузочное тестирование. Особенно проверяется обратная совместимость старого кода + новой схемы.

• Утверждение шлюза — утверждение MR или ITSM заявки до внедрения операции. Этапы зависят от уровня риска (низкий/средний/высокий), и номер заявки остается

• Обеспечение резервного копирования — резервное копирование сразу перед внедрением операции, резервное копирование также периодически тестируется на восстановление

• Постепенное применение — сначала применяются миграции с идемпотентными скриптами, затем развертывается код, который зависит от них. В сочетании с Expand–Contract исчезает зависимость от порядка

• Мониторинг + флаг функций — наблюдение за временем отклика, соединениями и уровнем ошибок сразу после применения. Новый функционал отделяется от схемы с помощью флагов функций

• Верификация отката — используйте только предварительно проверенные пути отката в подчиненной среде

Принцип, который здесь не будет упущен,Разделение полномочийЭто. Разработчики могут работать автономно в подчиненной среде, но реализация в эксплуатации осуществляется под контролем DBA и безопасности. Кроме того, в последнее время рекомендации говорят о том, что лучше использоватьявное версиями миграцийЭто связано с тем, что изменения предсказуемы, а аудит и воспроизведение легки.

Откат не заканчивается на "возврате"

в регулируемой среде,требуется, чтобы факты и содержание отката оставались как доказательстводо.

• Flyway — undo требует написания обратных скриптов, таких как U1__...sql, вручную, автоматический откат — это коммерческая функция. Откат также считается "еще одной миграцией", подлежащей проверке и регистрации.

• Liquibase — изменения в changelog автоматически генерируют несколько откатов, raw SQL предоставляет явный блок отката. В Secure выполняемые SQL-коды загружаются в отдельную таблицу, и генерируется отчет об откате (кто, когда, что, как).

Суть в том, что в системах, подлежащих аудиту,нельзя выполнять откаты вручную и немедленно в эксплуатации,это значит. Их следует выполнять только по проверенным путям с сохранением истории.

Модель, разделяющая создание и применение

По ту сторону автоматического применения CDинструмент только генерирует SQL, а применение выполняется DBA напрямую в окне изменениятакой модели. Это часто встречается в финансовых и государственных средах, где доступ к рабочим базам данных предоставляется лишь немногим.

Все три инструмента предоставляют команду "генерировать только SQL без применения".

• Flyway — flyway migrate -dryRunOutput=deploy.sql

• Liquibase — liquibase update-sql(применение), liquibase rollback-sql(откат)

• Атлас — atlas migrate diff <name>генерация версионированного SQL

Преимущества очевидны. Человек проверяет SQL напрямую, поэтому контроль, аудит и разделение правпроисходят естественным образом, и мы можем выполнять опасные изменения в контролируемый временной интервал.

Тем не менее, это имеет свою цену. Автоматическая развертка может быть прервана, увеличивая время вывода, и с увеличением числа арендаторов ручная работа становится узким местом. Самая большая ловушка — это дрифт.Если DBA вручную исправляет и выполняет созданные скрипты в производственной среде, это приводит к несоответствию между SSOT в Git и фактическим применением. Принцип заключается в том, что сгенерированные скрипты должны выполняться без изменений, а если нужно что-то исправить, то необходимо внести изменения в исходный код и заново сгенерироватьих.

Поэтому последнее компромиссное решение — "DBA проверяет и подтверждает, и изменения применяются в окне пайплайна"это модель гейт. Контроль человека сохраняется, но выполнение автоматизировано для совместного обеспечения доказательств и воспроизводимости. Bytebase, Liquibase Secure подходят для этой модели.

4. Практика - безостановочность и большие объемы

Самое сложное, чем воспользоваться инструментами, это изменить схему, не останавливая работающую систему.

Шаблон Expand–Contract

Это основа безостановочной работы. Изменения не производятся сразу, а разбиты на три этапа.

• Расширение (Expand) — добавление новых колонок и таблиц. Существующий код не затрагивается.

• Миграция и двойная запись (Migrate & Dual-write) — развёртывание с одновременным использованием старых и новых, а также бэктрекинг существующих данных.

• Сокращение (Contract) — после подтверждения того, что весь трафик использует новую структуру, удаляются устаревшие колонки и таблицы.

Таким образом, в любой момент развертывания приложение и схема будутвзаимосовместимостьЭто будет. Даже такая простая задача, как изменение имени столбца, может привести к тому, что старые экземпляры будут ссылаться на старый столбец во время рулевого развертывания, поэтому одноПЕРЕИМЕНОВАТЬТаким образом, происходят прерывания. Это следует решить с помощью "Добавить → Запись с обеих сторон → Удалить".

Необратимое изменение

Удаление столбца, изменение типа, добавление NOT NULL выполняются одновременно с риском. Всегдаоставить один уровень обратной совместимостиРазделяем по направлениям. NOT NULL делится на (1) добавление столбца → (2) обратное заполнение существующих строк → (3) добавление ограничения.

Когда данных много

Когда миллионы строк накапливаются в таблице, это становится обычнымИЗМЕНИТЬ ТАБЛИЦУОдна строка становится проблемой. Изменение схемы в большинстве БД влияет на таблицузамок(lock)Это связано с тем, что чтение и запись заблокированы. Добавление индекса за считанные секунды на маленькой таблице занимает десятки секунд на большой таблице, захватывая блокировку и вызывая задержки API и переполнение пула соединений.

В больших объемах используются следующие методы.

• Изменение схемы в онлайне — если это MySQL, то gh-ost, pt-online-schema-change. Вместо оригинала создается теневая таблица и данные постепенно копируются, после чего изменения синхронизируются, а в конце производится мгновенная замена.

• Пакетный бэкфилл — если обновить UPDATE миллионы строк за раз, транзакция становится громоздкой и возникает задержка репликации. Заполняйте, разбивая на тысячи или десятки тысяч строк, следя за нагрузкой.

• Большой индекс — PostgreSQLCREATE INDEX CONCURRENTLYиспользует опцию, которая не блокирует запись. Поскольку она должна выполняться вне транзакции, необходимо учесть опцию разделения транзакции в инструменте миграции.

Принцип один. Изменения в больших таблицах не должны происходить сразу, а должны быть разбиты на части и выполняться постепенно.

Примеры из нашей страны

① Внедрение Flyway — Команда, зависевшая от JPA ddl-autoстолкнулась с проблемой несовпадения локальных, тестовых и производственных схем, а также с реальностью "DROP таблицы в производстве опасен", и поэтому внедрила Flyway. В производстве используется ddl-auto: validateчтобы предотвратить запуск, если существует несоответствие между сущностью и схемой, а изменения применяются только с помощью версионированных скриптов.flyway_schema_historyОбнаружение манипуляций с помощью контрольной суммы, новая версия добавлена без изменения примененного скриптапревратили в операционные правила. Как было показано ранее, validate·Пример принципа контрольной суммы остался неизменным. (Применение Flyway)

② Беспрерывная масштабная миграция — функция «Нравится» была перенесена с PostgreSQL на MySQL вместе со схемой, и из-за большого объема данных миграция заняла много времени. Поскольку остановка была невозможна, двойная записьбыла выбрана. Реестр оставался как V1, и изменения V1 были переданы в V2 через SQS (FIFO), чтобы сохранить порядок и согласованность. Исходные данные были перенесены с помощью скрипта, а изменения были собраны в SQS, которые были потреблены после развертывания V2, чтобы наверстать упущенное. Запросы предоставляли V1 и V2 одновременно, постепенно перенося все на V2, и подписка на SQS была идемпотентной для гарантии того, что последнее событие становится конечным состоянием. Ключевой момент, который отметил автор — это "как синхронизировать данные, которые продолжают обновляться во время миграции". (Отзыв о миграции)

5. Итак, что же выбрать?

Ответ зависит от того, для чего вы используете тот же инструмент.

Установленная SaaS платформа → Flyway

Если SaaS платформа отдельная Система распространения приложенийпо каналу Подписка → установка → отмена → очисткаавтоматически происходит, что будет?

Этот жизненный цикл требует двух вещей.

• Автоматическое создание схемы при установке, автоматическая очистка при отмене подписки — схема должна устанавливаться и удаляться на уровне приложения без участия людей. Подходящей моделью являетсямодель, в которой миграция встроена в приложение и распространяется вместе с кодом.

• Модульная независимость — миграция для каждого модуля отделена и имеет свою историю версий.

⚠️ В случае отмены подписки, если очистка не сможет очистить таблицу миграции, при повторной установке это может быть воспринято как "уже примененная версия", и начальная схема может не быть создана. При проектировании потока установки и очистки необходимо учитывать жизненный цикл истории.

Условие включает в себя Flywayчто отлично подходит. Автоматическое применение при запуске приложения проходит гладко, и SQL миграции по модулям могут быть непосредственно встроены в структуру приложения, а также просто интегрированы в потоки установки и очистки. Для повышения уровня управления конфигурацией и автоматизации Atlas + GitOpsвыбор для комбинации.

Если это проект сайта → по отраслям

отрасль	требования	рекомендации
финансовый сектор	Обязательны проверки, утверждение и доказательства отката. Самые строгие.	Liquibase(Secure) — блокировка несоответствующих изменений в качестве проверки политики, сопоставление SOX·PCI·DORA.Bytebaseдобавить в слой одобрения
медицинский	соблюдение конфиденциальности и норм, целостность данных и отслеживание истории.	Liquibase — явный changelog и управление откатом. Если требуется больше корпоративного управления одобрением, то Bytebaseдополнение
внутренний интранет	низкая регуляторная нагрузка и ограниченный операционный персонал. Простота на первом месте.	Flyway — легкая SQL операция

в заключение, от клиентов требуется какнасколько сильно они требуют стабильности и доказательства аудита (включая откат)В соответствии с этим вес смещается в сторону Flyway → Liquibase → Bytebase.

быстрый чек-лист

• Миграция распространение с приложениемДолжно ли быть? → Flyway

• Несколько СУБД, явный откат, Доказательства регулирования (SOX·PCI·DORA)Это важно? → Liquibase(Безопасно)

• Обзор·утверждение рабочего процессанужно ли принудительно использовать GUI? → Bytebase

• Декларативное управление конфигурациейи возможность автоматизации GitOps? → Atlas

6. В заключение

Самое важное при выборе инструмента это не сам инструмент, а окружающий его рабочий процессЕсли модель развивается, то и схема должна развиваться, и наличие процедура, которая делает изменения отслеживаемыми, безопасными и позволяющими откат, решает половину задач, независимо от используемого инструмента.

Платформа с автоматизированным жизненным циклом может удовлетворить требования простоты и легкости интеграции, а для клиентов, где важен аудит и контроль, как в финансах и медицине, важно выбрать инструменты с сильным управлением в соответствующем контексте. Если вы рассматриваете внедрение,лучше выбрать одну из наиболее изменяемых услуг и начать с небольшого пайплайна.это будет более безопасно.

dnine