LabHub

ブログ

DBマイグレーションツール 2026 — Atlas・Bytebase・Skeema・Liquibase・Flyway・Prisma・Drizzle・gh-ost・pg-osc 徹底比較(宣言的 vs 命令的、レビューワークフロー、オンラインDDL)

2026-05-14 · 32 分で読めます · #database-migration#atlas#bytebase#liquibase#flyway#skeema#prisma-migrate#drizzle-kit#schema-management#japanese

한국어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シャドウテーブル + トリガ + カットオーバー
クラウドマネージド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 を計算し、対応する 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 とクラウド SaaS(Atlas Cloud)が付いてくる。

核は三つ。

  1. 宣言的と命令的の両方をサポート。 atlas schema apply は宣言的、atlas migrate diff + atlas migrate apply は命令的。
  2. Schema Monitoring(2024 年導入)— 本番 DB を定期的にスナップショットし、コード側のスキーマと比較してドリフトを検出する。
  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 の最大の差別化要因は ドリフト検出の自動化 だ。誰かが本番で直接 ALTER TABLE を打った事実、または hotfix migration が staging に適用されたが本番には適用されていない事実を、ツールが教えてくれる。

# 本番を定期的にスナップショット
atlas schema monitor \
  --url "postgres://prod.../app" \
  --token "$ATLAS_TOKEN" \
  --interval 1h

ドリフトがあれば Slack やメールで通知。これは Flyway・Liquibase・Prisma Migrate にはないカテゴリだ。

3.4 Versioned Migrations + Lint

命令的ワークフローを好むなら Atlas の versioned モードを使う。

# 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) 生成された migration の危険 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 — レビューワークフローを第一級市民に

4.1 何が違うか

Bytebase は中国出身のオープンソース + 商用の会社。他のツールが CLI を中心に置くのに対し、Bytebase は GUI + 承認ワークフロー を中心に置く。

開発者 → 変更提案(PR ライクな 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 圏の軽量宣言型

Skeema は単純さの権化だ。MySQL 用に始まり、2025 年に Postgres 対応が GA。

schemas/
  - app/
      - users.sql     # CREATE TABLE users (...)
      - posts.sql
      - .skeema       # 接続情報

*.sql ファイルに CREATE TABLE 文をそのまま 書く。skeema diff・skeema push で DB と同期。

MySQL を使いつつ軽量なツールが欲しいなら最初の候補。Atlas と比べた学習コストはほぼゼロ。

6章 · Liquibase — 持続可能なエンタープライズの選択

6.1 何が違うか

Liquibase は 2006 年から存在する。Java 圏の標準だが、Java アプリ以外でもよく使われる。

核心概念:ChangeSet。変更一つが一つの ChangeSet で、それぞれが id・author・ロールバック 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 で戻す。明示的なロールバック 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 で適用。ロールバックは別途の U2__... down ファイル、または新しい forward migration で解決。

7.1 2025〜2026 の変化

7.2 Flyway を選ぶべき人

弱点:Community 版ではロールバックが第一級市民ではない。複雑な変更追跡では Liquibase の方が強い。

8章 · Prisma Migrate・Drizzle Kit — ORM とセット

8.1 Prisma Migrate

schema.prisma(宣言的)と 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")
}

# 新規 migration の生成と適用(開発用)
npx prisma migrate dev --name add_user_table

# 本番適用
npx prisma migrate deploy

8.2 Drizzle Kit

// schema.ts (Drizzle スキーマ)
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 億行のテーブルに新カラムを追加したら? 多くの DDL はメタデータロックを取る。MySQL 8.0 以降は多くの DDL がオンラインだが、依然としてロックリスクのある変更はある。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 で欠落変更を追従 → 短時間ロックでカットオーバー。

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)

比較的後発。シャドウテーブル + トリガ + カットオーバーのパターンを 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+ で高速に処理するが、型変更・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(宣言的) — 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 をバッチで実行(UPDATE ... WHERE id BETWEEN ... AND ...)。
  2. アプリケーションコードが NULL を書き込まないように修正・デプロイ。
  3. NOT NULL 制約を追加 — 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. アプリケーションを display_name だけを読み書きするように変更しデプロイ。
  3. ずっと後 — name カラムを削除。

Flyway・Liquibase — 上記 1〜3 をそれぞれ明示的に書く。

Atlas(宣言的) — schema.hcl でカラム名を変えるとツールはデフォルトで drop + add と認識する。rename ヒントを明示的に書く必要:

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 に置き換える。コード側の名前は @map・varchar('display_name') マッピングで別に保つ。

教訓:リネームはどのツールでも自動 diff に 100% は任せない。人の確認が必須。

11章 · 7 軸比較 — 一目で

11.1 宣言的 vs 命令的

ツール宣言的命令的
Atlasはい(schema apply)はい(migrate diff/apply)
Skeemaはいいいえ
Drizzle Kitはい(スキーマ)はい(生成 SQL)
Prisma Migrateはい(db push、dev)はい(migrate deploy)
Liquibaseいいえはい
Flywayいいえはい
Bytebase一部はい

11.2 複数 DB サポート

ツールPostgresMySQLSQLiteOracleSQL Serverその他
Atlasはいはいはい一部はい一部 ClickHouse
Bytebaseはいはいはいはいはい25 種類以上
LiquibaseはいはいはいはいはいDB2・Snowflake 他
Flywayはいはいはいはいはい多数
Skeemaはいはいいいえいいえいいえ-
PrismaはいはいはいいいえはいMongoDB(制限)
DrizzleはいはいはいいいえいいえD1・LibSQL 他

11.3 レビューワークフロー

ツールビルトインレビュー自動 lintLLM レビュー
Bytebaseはい(GUI)はいはい
Atlas Cloudはいはい一部
Liquibase Hubはいはいはい(Advisor)
Flyway Enterprise一部一部導入中
その他(CLI)いいえ(Git PR で代替)いいえいいえ

11.4 ドリフト検出

ツール自動ドリフト検出備考
Atlas(Cloud)はい最も成熟
BytebaseはいGUI で
Liquibase一部history テーブルベース
Flyway一部history テーブルベース
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(ツール本人)--
Atlasいいえはい(Lint)いいえ(手動)
Bytebase Enterprise一部はいはい
Liquibaseいいえ一部いいえ
その他いいえいいえいいえ

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 Java・Spring Boot 中心のエンタープライズ

12.5 大規模テーブルが核(10 億行+)

12.6 マルチクラウド・複数 DB エンジン(Postgres + MySQL + Snowflake など)

13章 · アンチチェックリスト

避けるべきパターン。

  1. 一つの DB に二つのマイグレーションツールを並行運用 — Prisma Migrate が作る _prisma_migrations と Flyway の flyway_schema_history が同時に存在。真実の源が二つ。
  2. 自動 diff を 100% 信頼 — カラムリネームは drop + add と認識される。人が見る。
  3. ロールバック無しの破壊的変更 — DROP COLUMN を本番直前にマージし、問題が起きたらバックアップから復元? 駄目。expand-contract で解く。
  4. 大規模テーブルへの無条件 DDL — ロックが長く居座る。NOT NULL 導入前にバックフィル + NOT VALID パターン。
  5. ドリフトを検出していない本番 — 誰かが 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. 本番は migrate deploy(Prisma)または drizzle-kit migrate。シャドウ DB を使用。
  5. Atlas Cloud(または同等)でドリフト検出 — 直接打たれた ALTER を捕える。
  6. 大規模テーブル変更は gh-ost/pg-osc に分離 — マイグレーションファイルはプレースホルダだけ残し、実際の変更は runbook に書かれた外部ツールで。
  7. expand-contract パターンを義務化 — 破壊的変更は絶対に一 PR では行かない。

エンタープライズなら上に Bytebase の承認ゲートが追加される。Java 圏なら 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. ロールバック無しの破壊的変更。
  4. 大規模テーブルへの無条件 NOT NULL。
  5. CI でマイグレーション lint 無し。
  6. ドリフト検出無しの本番。
  7. 環境間スキーマ不整合の放置。

次回予告

候補:Atlas を一ヶ月使った後の所感 — HCL は本当に SQL より良いか、gh-ost vs pt-online-schema-change 実測 — 1 億行のテーブルで、Bytebase + GitHub Actions で作る DB 変更自動化パイプライン。

「スキーマは事実であり、マイグレーションはその事実を運ぶ道だ。ツールは道を安全にしてくれるだけで、道自体を代わりに歩いてはくれない。」

— DB マイグレーションツール 2026、終わり。

参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます