핵심 차이

변경을 무엇으로 식별하느냐가 운영 방식을 바꿉니다.

두 도구 모두 DB 스키마 변경을 자동 적용하지만, Flyway는 "버전 파일이 몇 번째인가"를 중심으로, Liquibase는 "이 변경 항목이 무엇인가"를 중심으로 이력을 남깁니다. 그래서 단순한 순차 배포와 여러 DB 환경 운영에서 선택 기준이 갈립니다.

같은 출발점
요청된 변경 users.email 컬럼 추가 NOT NULL 제약 반영 배포 시점에 자동 적용
비교 축
Flyway SQL 파일 순서가 곧 적용 순서
Liquibase changeset이 변경의 정체성
작성
SQL 파일을 그대로 배포합니다. DB 문법이 바로 보여서 읽기 쉽고, 팀이 SQL 중심으로 일할 때 시작 비용이 낮습니다.
V1__create_users.sql V2__add_email.sql
변경을 changeset으로 설명합니다. XML, YAML, SQL 등으로 같은 변경을 기술할 수 있어, DB별 차이를 추상화하기 좋습니다.
changeSet: add-email addColumn users.email
이력
파일명 버전이 실행 순서입니다. `V1 -> V2 -> V3`처럼 보이는 순서가 곧 운영 규칙이라서, "어떤 SQL이 언제 적용됐는가"를 직관적으로 따라가기 쉽습니다.
각 changeset이 추적 단위입니다. 파일 안 순서보다 변경 항목의 ID와 작성자 기준으로 이력을 관리해, 세밀한 추적과 정책화에 더 적합합니다.
운영
한 DB 계열에서 단순하게 굴리기 좋습니다. SQL이 곧 진실의 원본이라 디버깅은 쉽지만, DB 제품이 바뀌면 스크립트 차이를 직접 감당해야 합니다.
롤백과 멀티 DB 정책에 유리합니다. 변경 정의를 구조적으로 다루기 때문에, 환경별 차이를 흡수하거나 공통 배포 규칙을 유지하기 쉽습니다.
이럴 때 선택
SQL 중심, 단일 DB, 빠른 이해가 중요하면 Flyway

버전 파일 순서만 맞추면 운영 규칙이 명확하게 유지됩니다.

이럴 때 선택
여러 DB 환경, 롤백 정책, 구조적 추적이 중요하면 Liquibase

변경 항목 자체를 관리 단위로 삼아 운영 통제를 더 세밀하게 가져갑니다.