LabHub

블로그

DB 마이그레이션 도구 2026 — Atlas·Bytebase·Skeema·Liquibase·Flyway·Prisma·Drizzle·gh-ost·pg-osc 심층 비교 (선언형 vs 명령형, 리뷰 워크플로, 온라인 DDL)

2026-05-14 · 36 분 읽기 · #database-migration#atlas#bytebase#liquibase#flyway#skeema#prisma-migrate#drizzle-kit#schema-management

한국어English日本語

프롤로그 — 마이그레이션 도구는 왜 여전히 어려운가

DB 스키마 변경은 소프트웨어에서 가장 위험한 작업 중 하나다. 코드 배포는 롤백이 쉽지만, ALTER TABLE은 한 번 실행되면 디스크 위의 사실이 된다. 큰 테이블에 잘못 락이 걸리면 서비스가 멈춘다.

그래서 마이그레이션 도구가 존재한다. 하지만 2026년 5월 현재 이 카테고리는 어느 때보다 분열되어 있다.

이 글은 이 도구들을 선언형 vs 명령형, 리뷰 워크플로, 드리프트 감지, 다중 DB, AI 어시스턴스, 온라인 DDL 안전성의 축으로 비교한다. 실전 시나리오 — 칼럼 추가, NOT NULL 도입, 대형 테이블 백필, 롤링 리네임 — 를 각 도구로 풀어보고, 팀별 결정 프레임워크를 제시한다.

이 글은 패턴 가이드가 아니라 도구 비교다. 무중단 expand-contract 패턴 자체는 이미 별도 글에서 다뤘다(2026-04-15 zero-downtime database migration 참고). 여기서는 그 패턴을 어느 도구로 어떻게 굴리는지가 핵심이다.

1장 · 풍경 — 도구 지도

먼저 도구를 분류한다. 한 줄에 다 들어가지 않는다.

분류도구한 줄 요약
선언형 schema-as-codeAtlas, Skeema, Drizzle Kit"있어야 할 상태"를 적으면 diff를 만든다
명령형 migration-filesLiquibase, Flyway, Prisma Migrate, dbmate, Sqitch"무엇을 바꿀지" 한 파일씩 직접 적는다
리뷰 워크플로 중심Bytebase, Atlas CloudPR·승인·롤백·실행을 한 화면에서
온라인 DDL (큰 테이블 전용)gh-ost, pt-online-schema-change, pg-online-schema-change쉐도우 테이블 + 트리거 + cutover
클라우드 매니지드Atlas Cloud, Bytebase Hub, Liquibase Hub실행 로그·승인·드리프트 감지 SaaS

이 글의 초점은 굵게 표시된 도구들이다. Atlas·Bytebase·Skeema·Liquibase·Flyway·Prisma Migrate·Drizzle Kit, 그리고 온라인 DDL 도구들.

왜 이 도구들인가

2장 · 선언형 vs 명령형 — 가장 큰 분기점

DB 마이그레이션 도구 선택의 첫 분기점이다. 무엇을 적는가가 다르다.

선언형 (declarative, schema-as-code)

"있어야 할 상태"를 적는다. 도구가 현재 DB와 비교해 diff를 만들고, 그 diff에 해당하는 DDL을 실행한다.

# Atlas: schema.hcl — 있어야 할 상태
table "users" {
  schema = schema.public
  column "id"    { type = bigint, null = false }
  column "email" { type = varchar(255), null = false }
  column "name"  { type = varchar(100), null = true }
  primary_key { columns = [column.id] }
  index "users_email_uniq" {
    unique  = true
    columns = [column.email]
  }
}

명령형 (imperative, migration-files)

"무엇을 바꿀지"를 한 파일씩 적는다. 각 파일은 한 번 실행되면 끝.

-- Flyway: V001__add_users_table.sql
CREATE TABLE users (
  id    BIGINT       PRIMARY KEY,
  email VARCHAR(255) NOT NULL UNIQUE,
  name  VARCHAR(100)
);

-- V002__add_users_created_at.sql
ALTER TABLE users ADD COLUMN created_at TIMESTAMPTZ DEFAULT now();

어느 쪽이 우월한가

둘 다 우월하지 않다. 다만 2026년의 분위기는 분명하다:

3장 · Atlas — 부상하는 강자

3.1 무엇이 다른가

Atlas는 이스라엘의 Ariga 사가 만든 오픈 소스 DB 스키마 도구다. Go로 작성됐고, 단일 바이너리, HCL DSL, 그리고 cloud SaaS(Atlas Cloud)가 따라온다.

핵심은 세 가지.

  1. 선언형과 명령형을 모두 지원한다. atlas schema apply는 선언형, atlas migrate diff + atlas migrate apply는 명령형.
  2. Schema Monitoring(2024년 도입) — production DB를 주기적으로 스냅숏 뜨고, 코드의 schema와 비교해 드리프트를 감지한다.
  3. Schema Lint·Schema Versioning — atlas migrate lint로 위험 DDL(예: 비조건적 NOT NULL 도입)을 사전에 잡는다.

3.2 HCL 스키마

# schema.hcl
schema "public" {
  comment = "core application"
}

table "users" {
  schema = schema.public
  column "id" {
    type = bigint
    null = false
  }
  column "email" {
    type = varchar(255)
    null = false
  }
  column "created_at" {
    type    = timestamptz
    null    = false
    default = sql("now()")
  }
  primary_key {
    columns = [column.id]
  }
  index "users_email_uniq" {
    unique  = true
    columns = [column.email]
  }
}

atlas schema apply --url "postgres://..." --to "file://schema.hcl" 한 줄로 현재 DB를 이 상태로 맞춘다. 미리 보고 싶다면 atlas schema diff.

3.3 Schema Monitoring — 새 카테고리

Atlas Cloud의 가장 큰 차별점은 드리프트 감지의 자동화다. 누군가 production에서 직접 ALTER TABLE을 친 사실, 또는 hotfix migration이 staging에는 적용되고 production에는 적용 안 된 사실을 도구가 알려준다.

# 주기적으로 production을 스냅숏
atlas schema monitor \
  --url "postgres://prod.../app" \
  --token "$ATLAS_TOKEN" \
  --interval 1h

드리프트가 있으면 Slack·이메일로 알림. 이건 Flyway·Liquibase·Prisma Migrate에는 없는 카테고리다.

3.4 Versioned Migrations + Lint

명령형 워크플로를 선호한다면 Atlas의 versioned mode를 쓴다.

# 1) 코드의 schema.hcl과 현재 migration history를 비교해 새 SQL 파일 생성
atlas migrate diff add_user_table \
  --dir "file://migrations" \
  --to "file://schema.hcl" \
  --dev-url "docker://postgres/16/dev"

# 2) 위험 DDL이 있는지 lint
atlas migrate lint --dir "file://migrations" --latest 1

# 3) 적용
atlas migrate apply --dir "file://migrations" --url "$DB_URL"

atlas migrate lint는 다음 같은 패턴을 잡는다.

3.5 누가 Atlas를 쓰면 좋은가

4장 · Bytebase — 리뷰 워크플로 1급 시민

4.1 무엇이 다른가

Bytebase는 중국 출신의 오픈 소스 + 상용 회사. 다른 도구들이 CLI를 중심에 두는 반면, Bytebase는 GUI + 승인 워크플로를 중심에 둔다.

개발자 → 변경 제안(PR-like Issue) → SQL Review(자동·사람)
       → DBA 승인 → 단계적 환경 적용(dev → staging → prod)
       → 자동 백업·롤백 스크립트 보존

4.2 AI 어시스턴트 (2025~2026)

Bytebase 3.x부터 추가된 기능.

이 카테고리는 다른 도구들이 아직 깊게 못 따라왔다. Atlas도 자체 AI를 붙이고는 있지만 Bytebase가 가장 성숙하다.

4.3 누가 Bytebase를 쓰면 좋은가

누가 쓰지 말 것: 1인 또는 소규모 팀. 오버킬이다. Drizzle Kit + Atlas migrate가 충분.

5장 · Skeema — MySQL 진영의 가벼운 declarative

Skeema는 단순함의 화신이다. MySQL용으로 시작했고 2025년에 Postgres 정식 지원.

schemas/
  ├─ app/
  │   ├─ users.sql     # CREATE TABLE users (...)
  │   ├─ posts.sql
  │   └─ .skeema       # connection info

*.sql 파일에 CREATE TABLE 문 그대로 적는다. skeema diff·skeema push로 DB와 동기화.

MySQL을 쓰면서 가벼운 도구를 원하면 가장 먼저 검토할 후보. Atlas와 비교해 학습 곡선이 거의 0이다.

6장 · Liquibase — 엔터프라이즈의 지속 가능한 선택

6.1 무엇이 다른가

Liquibase는 2006년부터 있다. 자바 진영의 표준이지만 자바 앱이 아닌 곳에서도 잘 쓰인다.

핵심 개념: ChangeSet. 변경 하나가 하나의 ChangeSet이고, 각각이 id·author·rollback SQL을 명시적으로 갖는다.

# changelog.yaml
databaseChangeLog:
  - changeSet:
      id: 001-create-users
      author: alice
      changes:
        - createTable:
            tableName: users
            columns:
              - column: { name: id, type: BIGINT, constraints: { primaryKey: true } }
              - column: { name: email, type: VARCHAR(255), constraints: { nullable: false, unique: true } }
              - column: { name: name, type: VARCHAR(100) }
      rollback:
        - dropTable: { tableName: users }

liquibase update로 적용, liquibase rollback으로 되돌림. 명시적인 rollback SQL이 큰 차이점이다.

6.2 2025~2026의 변화

6.3 누가 Liquibase를 쓰면 좋은가

약점: XML/YAML은 SQL을 직접 쓸 때보다 장황하다. Drizzle Kit·Atlas와 비교해 신규 팀에는 무거울 수 있다.

7장 · Flyway — 단순함의 미학

Flyway는 더 단순하다. 파일 이름으로 버전을 매기고, SQL을 그대로 적는다.

db/migration/
  ├─ V1__create_users.sql
  ├─ V2__add_users_created_at.sql
  └─ V3__add_users_email_index.sql

-- V2__add_users_created_at.sql
ALTER TABLE users ADD COLUMN created_at TIMESTAMPTZ DEFAULT now();

flyway migrate로 적용. rollback은 별도 down 파일(U2__...) 또는 새 forward migration으로 푼다.

7.1 2025~2026 변화

7.2 누가 Flyway를 쓰면 좋은가

약점: rollback이 1급 시민이 아니다(community edition). 복잡한 변경에는 Liquibase가 더 강하다.

8장 · Prisma Migrate · Drizzle Kit — ORM과 한 묶음

8.1 Prisma Migrate

schema.prisma(declarative)와 prisma migrate(versioned)의 조합.

// schema.prisma
model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique @db.VarChar(255)
  name      String?  @db.VarChar(100)
  createdAt DateTime @default(now()) @map("created_at")
  @@map("users")
}

# 새 마이그레이션 생성 + 적용 (개발용)
npx prisma migrate dev --name add_user_table

# 프로덕션 적용
npx prisma migrate deploy

8.2 Drizzle Kit

// schema.ts (드리즐 스키마)
import { pgTable, bigserial, varchar, timestamp, uniqueIndex } from 'drizzle-orm/pg-core'

export const users = pgTable('users', {
  id: bigserial('id', { mode: 'bigint' }).primaryKey(),
  email: varchar('email', { length: 255 }).notNull(),
  name: varchar('name', { length: 100 }),
  createdAt: timestamp('created_at', { withTimezone: true }).defaultNow().notNull(),
}, (t) => ({
  emailUniq: uniqueIndex('users_email_uniq').on(t.email),
}))

# 스키마와 DB를 비교해 SQL 파일 생성
npx drizzle-kit generate

# 적용
npx drizzle-kit migrate

8.3 ORM 마이그레이션 vs Atlas/Liquibase

9장 · 온라인 DDL — 큰 테이블의 무중단

위 도구들의 공통점: DB가 직접 ALTER TABLE을 실행한다는 가정. 작은 테이블이면 문제없다. 그러나 1억 row 테이블에 새 컬럼을 추가하면? 대부분의 DDL이 메타데이터 락을 잡는다. MySQL은 8.0 이후 많은 DDL이 online이지만, 여전히 락 위험이 있는 변경이 있다. Postgres는 12+ 이후 많이 좋아졌지만 일부 변경은 여전히 ACCESS EXCLUSIVE 락.

그래서 온라인 DDL 도구가 필요하다.

9.1 gh-ost (MySQL)

GitHub이 만든 도구. 트리거를 쓰지 않고 binlog만 본다. 부하가 낮다.

gh-ost \
  --user=admin --password=*** --host=mysql.prod \
  --database=app --table=users \
  --alter="ADD COLUMN status VARCHAR(20) DEFAULT 'active'" \
  --max-load=Threads_running=25 \
  --critical-load=Threads_running=1000 \
  --chunk-size=2000 \
  --execute

작동: 쉐도우 테이블 생성 → 청크 단위 복사 → binlog로 누락 변경 따라잡기 → 짧은 락으로 cutover.

9.2 pt-online-schema-change (MySQL)

Percona Toolkit의 일부. gh-ost보다 오래됐고, 트리거 기반이다.

pt-online-schema-change \
  --alter="ADD COLUMN status VARCHAR(20) DEFAULT 'active'" \
  --execute \
  D=app,t=users,h=mysql.prod

장점: 더 오래 검증됐고 더 다양한 환경에서 돈다. 단점: 트리거가 INSERT/UPDATE/DELETE에 매번 따라붙어 부하가 있다.

9.3 pg-online-schema-change (Postgres)

상대적으로 후발 주자. shadow table + 트리거 + cutover 패턴을 Postgres에 맞췄다. Shopify·Stripe 등이 만든 도구들이 있고 (pg-osc·pg_squeeze·pg_repack), 활용도가 늘고 있다.

pg-osc run \
  --dbname=app --table=users \
  --alter="ADD COLUMN status TEXT DEFAULT 'active'" \
  --copy-batch-size=10000

Postgres 자체가 ALTER TABLE ... ADD COLUMN(기본값 있는)을 12+에서 빠르게 처리하긴 하지만, type change·NOT NULL 도입·인덱스 재구성 같은 변경에는 여전히 도움이 된다.

9.4 Atlas/Bytebase + 온라인 DDL

도구 통합이 막 시작됐다.

10장 · 실전 시나리오 — 도구별 풀이

같은 변경을 도구별로 보면 차이가 극명하다. 시나리오 셋.

10.1 시나리오 A — 새 컬럼 추가 (status, 기본값 'active')

Flyway

-- V012__add_users_status.sql
ALTER TABLE users ADD COLUMN status VARCHAR(20) DEFAULT 'active' NOT NULL;

Liquibase

- changeSet:
    id: 012-add-users-status
    author: bob
    changes:
      - addColumn:
          tableName: users
          columns:
            - column:
                name: status
                type: VARCHAR(20)
                defaultValue: 'active'
                constraints: { nullable: false }
    rollback:
      - dropColumn: { tableName: users, columnName: status }

Prisma Migrate — schema.prisma에 status String @default("active") 추가 후 prisma migrate dev.

Drizzle Kit — schema.ts에 status: varchar('status', { length: 20 }).default('active').notNull() 추가 후 drizzle-kit generate.

Atlas (declarative) — schema.hcl에 column "status" 블록 추가, atlas schema apply.

Atlas (versioned) — 위와 같이 schema.hcl 수정 후 atlas migrate diff add_status → SQL 파일 자동 생성.

큰 테이블이라면 — Postgres 12+는 기본값 있는 컬럼 추가도 빠르지만, MySQL 8.0 이전이거나 매우 큰 테이블이면 gh-ost로 실행한다. Atlas Lint가 사전 경고.

10.2 시나리오 B — 기존 컬럼에 NOT NULL 도입 (백필 후)

가장 위험한 패턴 중 하나. 잘못하면 락이 길게 걸린다.

안전한 순서 (expand-contract 패턴 변형):

  1. 컬럼은 이미 있고 nullable. 백필 SQL을 batch로 실행 (UPDATE ... WHERE id BETWEEN ... AND ...).
  2. application 코드가 더 이상 NULL을 쓰지 않게 수정·배포.
  3. NOT NULL constraint를 추가 — Postgres 12+에서는 NOT VALID + VALIDATE CONSTRAINT 패턴으로 락 시간 최소화.

Flyway — 위 1~3을 각각 V-파일로 나누어 적는다.

Liquibase — addNotNullConstraint. 백필은 sql change 또는 별도 ChangeSet.

Atlas — schema.hcl에서 null = true를 null = false로 바꾼다. atlas migrate lint가 데이터가 있다면 경고한다(unsafe DDL).

Prisma/Drizzle Kit — 자동 diff는 ALTER TABLE ... ALTER COLUMN ... SET NOT NULL만 만든다. 백필은 사람이 별도 migration SQL로 추가해야 안전.

Bytebase — 자동 SQL Review가 "백필 없이 NOT NULL을 도입하려고 함"을 잡는다(룰을 켰다면).

10.3 시나리오 C — 컬럼 리네임 (name → display_name)

가장 골치 아픈 패턴. 자동 diff 도구들이 잘 못 잡는다 — drop + add로 인식한다.

모든 도구의 공통 안전한 순서 (롤링 리네임):

  1. display_name 추가. 트리거 또는 dual-write로 name ↔ display_name 동기화.
  2. application을 display_name만 읽고 쓰게 변경·배포.
  3. 한참 후 — name 컬럼 제거.

Flyway·Liquibase — 위 1~3을 각각 명시적으로 적는다.

Atlas (declarative) — schema.hcl에서 컬럼 이름을 바꾸면 도구는 기본적으로 drop + add로 본다. rename hint를 명시적으로 적어야 함:

column "display_name" {
  type = varchar(100)
  null = true
  comment = "renamed from name"
}
# 그리고 atlas migrate diff 시 --rename old_to_new 같은 힌트 필요

Prisma/Drizzle — 자동으로 drop + add를 만든다. 데이터 손실 위험. 반드시 마이그레이션 SQL을 손으로 수정해 ALTER TABLE ... RENAME COLUMN으로 바꾼다. ORM의 @map/varchar('display_name') 매핑으로 코드 이름은 따로 유지.

교훈: 리네임은 어떤 도구든 자동 diff에 100% 맡기지 않는다. 사람의 확인이 필수.

11장 · 7축 비교 — 한눈에

11.1 선언형 vs 명령형

도구선언형명령형
AtlasO (schema apply)O (migrate diff/apply)
SkeemaOX
Drizzle KitO (스키마)O (생성된 SQL)
Prisma MigrateO (db push, dev)O (migrate deploy)
LiquibaseXO
FlywayXO
Bytebase일부O

11.2 다중 DB 지원

도구PostgresMySQLSQLiteOracleSQL Server기타
AtlasOOO일부OClickHouse 일부
BytebaseOOOOO25종 이상
LiquibaseOOOOODB2·Snowflake 등
FlywayOOOOO다수
SkeemaOOXXX-
PrismaOOOXOMongoDB 제한
DrizzleOOOXXD1·LibSQL 등

11.3 리뷰 워크플로

도구빌트인 리뷰자동 lintLLM 리뷰
BytebaseO (GUI)OO
Atlas CloudOO일부
Liquibase HubOOO (Advisor)
Flyway Enterprise일부일부도입 중
나머지 (CLI)X (Git PR로 대체)XX

11.4 드리프트 감지

도구자동 드리프트 감지비고
Atlas (Cloud)O가장 성숙
BytebaseOGUI에서
Liquibase일부history table 기반
Flyway일부history table 기반
Skeema·Prisma·Drizzle제한도구 실행 시점에만

11.5 AI 어시스턴스 (2026)

도구AI 기능
Bytebase자연어→SQL, SQL Review, 변경 영향 분석
AtlasMigration lint + 일부 AI 추천
LiquibaseHub Advisor (LLM 리뷰)
나머지외부 도구(Copilot, Cursor)에 의존

11.6 온라인 DDL 통합

도구직접 지원안전한 lintgh-ost 라우팅
gh-ost·pt-osc·pg-osc(도구 본인)--
AtlasXO (Lint)X (수동)
Bytebase Enterprise일부OO
LiquibaseX일부X
나머지XXX

11.7 ORM 통합 매끄러움

도구TypeScript ORMJava/KotlinPythonGo
Prisma Migrate최고(자체)---
Drizzle Kit최고(자체)---
Atlas좋음(Atlas + ORM)좋음(Atlas + JPA)좋음(Atlas + SQLAlchemy)최고 (Atlas 본가)
Liquibase보통최고 (Spring)좋음보통
Flyway보통최고 (Spring)좋음보통
Skeema보통보통보통보통

12장 · 팀별 결정 프레임워크

도구 결정의 첫 번째는 도구의 우월성이 아니라 팀의 모양이다.

12.1 1~3인 풀스택 팀 (TS/Next.js)

12.2 10~30인 다중 팀, TS 메인 (스타트업)

12.3 50인+ 다중 DB 다중 서비스 (mid-stage 스타트업)

12.4 자바·Spring Boot 위주 엔터프라이즈

12.5 큰 테이블이 핵심 (10억 row+)

12.6 멀티 클라우드·멀티 DB 엔진 (Postgres + MySQL + Snowflake 등)

13장 · 안티 체크리스트

피해야 할 패턴들.

  1. 두 개의 마이그레이션 도구를 한 DB에 동시에 운영 — Prisma Migrate가 만든 _prisma_migrations과 Flyway의 flyway_schema_history가 동시에 존재. 진실의 원천이 둘.
  2. 자동 diff를 100% 신뢰 — 컬럼 리네임은 drop + add로 인식된다. 사람이 본다.
  3. rollback 없이 destructive change — DROP COLUMN을 production 직전에 머지하고, 문제 생기면 백업에서 복원? 안 된다. expand-contract로 풀어야.
  4. 큰 테이블에 비조건적 DDL — 락이 길게 걸린다. NOT NULL 도입 전 백필 + NOT VALID 패턴.
  5. 드리프트를 감지 안 하는 production — 누군가 ALTER TABLE을 직접 친 사실을 1년 뒤에 알면 늦다.
  6. CI에서 마이그레이션 lint 없음 — atlas migrate lint 또는 Liquibase/Bytebase 룰. 사람 리뷰가 만능이 아니다.
  7. dev/staging/prod 사이 스키마 불일치 방치 — 한 환경에서만 hotfix 적용. 다음 마이그레이션이 어디서 깨질지 모름.

14장 · 실전 권장 워크플로 (참고용)

작은 팀, TS 스택을 가정한 한 가지 권장 워크플로.

  1. 스키마는 Drizzle 코드 (또는 Prisma schema). ORM과 한 묶음.
  2. 마이그레이션 SQL은 자동 생성 + 사람 리뷰. drizzle-kit generate 또는 prisma migrate dev로 생성된 SQL 파일을 PR로.
  3. CI에서 atlas migrate lint 또는 비슷한 lint — 위험 DDL 사전 차단.
  4. production은 migrate deploy (Prisma) 또는 drizzle-kit migrate. 셰도우 DB 사용.
  5. Atlas Cloud(또는 동등)로 드리프트 감지 — 누가 직접 친 ALTER를 잡는다.
  6. 큰 테이블 변경은 gh-ost/pg-osc로 분리 — 마이그레이션 파일은 placeholder만 남기고, 실제 변경은 runbook에 적힌 외부 도구로.
  7. expand-contract 패턴 의무화 — destructive change는 절대 한 PR로 가지 않는다.

엔터프라이즈라면 위에 Bytebase의 승인 게이트가 추가된다. 자바 진영이라면 Liquibase가 1, 2번을 대체한다.

에필로그 — 도구는 정책의 표현이지 정책 자체가 아니다

DB 마이그레이션 도구 선택은 "declarative냐 imperative냐"의 종교 전쟁이 아니다. 팀이 무엇을 보호하려고 하는지의 함수다.

2026년 5월의 풍경에서 가장 큰 변화는 두 가지다.

  1. Atlas의 부상 — declarative + lint + 드리프트 감지를 한 도구로 묶어 점유율을 빠르게 늘리고 있다. Terraform이 인프라에 한 일을 DB에 하고 있다는 평가가 과장은 아니다.
  2. AI 어시스턴스가 카테고리 — Bytebase·Liquibase Hub·Atlas 모두 LLM 기반 리뷰·자연어 변환을 붙였다. 마이그레이션 lint는 더 이상 룰 기반만이 아니다.

결정 체크리스트

안티 패턴 요약

  1. 자동 diff를 100% 신뢰.
  2. 한 DB에 두 마이그레이션 도구 공존.
  3. rollback 없이 destructive change.
  4. 큰 테이블에 비조건적 NOT NULL.
  5. CI에서 마이그레이션 lint 없음.
  6. 드리프트 감지 없는 production.
  7. 환경 간 스키마 불일치 방치.

다음 글 예고

다음 글 후보: Atlas 한 달 써본 후기 — HCL이 정말 SQL보다 좋은가, gh-ost vs pt-online-schema-change 실측 — 1억 row 테이블에서, Bytebase + GitHub Actions로 만드는 DB 변경 자동화 파이프라인.

"스키마는 사실이고, 마이그레이션은 그 사실을 옮기는 길이다. 도구는 길을 안전하게 만들어 줄 뿐, 길 자체를 대신 걸어주진 않는다."

— DB 마이그레이션 도구 2026, 끝.

참고 / References

원문 보기: https://www.youngju.dev/blog/culture/2026-05-14-database-migration-tools-2026-atlas-bytebase-skeema-liquibase-flyway-pg-online-comparison-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다