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

プロローグ — マイグレーションツールはなぜ今も難しいのか

DBスキーマ変更はソフトウェアで最も危険な作業の一つだ。コードのデプロイはロールバックしやすいが、ALTER TABLE は一度走ると即座にディスク上の事実になる。大きなテーブルでロックの掛け方を誤れば、サービスは止まる。

だからマイグレーションツールが存在する。しかし 2026 年 5 月現在、このカテゴリは過去にないほど分裂している。

• Liquibase と Flyway は 2010 年代以来、Java 圏の事実上の標準であり、今もエンタープライズの既定だ。
• Prisma Migrate・Drizzle Kit は TypeScript アプリの既定として定着した。ORM とセットなので最もなめらか。
• Atlas (Ariga) は HCL 由来の宣言的 schema-as-code で急速にシェアを伸ばしている。Schema Monitoring・Schema Lint・Versioned Migrations を一つのツールで。
• Bytebase はレビューワークフローを第一級市民にした。複数 DB・GitOps・AI アシスタントまで。
• Skeema は MySQL 圏で最も軽量な宣言的ツールとして生き残り、Postgres にも対応した。
• そして生きている大きなテーブルには、今でも gh-ost・pt-online-schema-change・pg-online-schema-change といったオンライン DDL ツールが必要だ。

本稿はこれらのツールを 宣言的 vs 命令的、レビューワークフロー、ドリフト検出、複数 DB、AI 支援、オンライン DDL の安全性の軸で比較する。実戦シナリオ — カラム追加、NOT NULL 導入、大規模テーブルのバックフィル、ローリングリネーム — を各ツールで解き、チーム別の決定フレームワークを示す。

本稿はパターンガイドではなくツール比較である。無停止 expand-contract パターン自体は別記事(2026-04-15 zero-downtime database migration 参照)で扱った。ここでは、そのパターンをどのツールでどう回すかが焦点だ。

1章 · 風景 — ツールマップ

まずツールを分類する。一行に収まらない。

本稿の焦点は太字のツール — Atlas・Bytebase・Skeema・Liquibase・Flyway・Prisma Migrate・Drizzle Kit、そしてオンライン DDL ツール群。

なぜこれらか

• Atlas — 2024〜2026 で最速で成長したツール。HCL DSL + Go 単一バイナリ + Schema Monitoring がセット。「Terraform がインフラに対して行ったことを、DB に対して行っている」と評される。
• Bytebase — レビューワークフロー・承認・複数 DB の事実上の標準。2025 年から AI アシスタント(SQL Review・自然言語→SQL)が合流。
• Skeema — MySQL の宣言的ツール。軽くて速い。2025 年に Postgres 対応が GA。
• Liquibase — XML/YAML/JSON/SQL すべてに対応。変更ログとロールバック SQL を明示的に書く伝統。エンタープライズ・銀行で事実上の標準。
• Flyway — 単純さの美学。SQL ファイルにバージョン番号を付けて終わり。2025 年から polyglot 対応を拡大。
• Prisma Migrate・Drizzle Kit — それぞれの ORM と同居。最もなめらかな統合。
• gh-ost・pt-osc・pg-osc — 上のツールができないことをやる。生きた大規模テーブルへの無停止 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]
  }
}

• 長所:スキーマが一箇所に集まる。コードレビューが「スキーマそのもの」を見る。
• 短所:自動 diff が安全とは限らない。ツールが生成した DDL を人が再度読む。

命令的(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();

• 長所:何が走るか人が正確に分かる。ロールバック SQL を別途書ける。
• 短所:スキーマ全体像は N 個のファイルを頭で結合しないと見えない。コンフリクト・マージ・リネームが難しい。

どちらが優れているか

どちらも一方的に優れてはいない。 ただし 2026 年の空気は明確だ:

• 新規フルスタックチームは 宣言的 で始める比率が増えた(Drizzle Kit・Atlas・Prisma db push)。
• エンタープライズ・銀行・規制業界はいまだ 命令的 が優勢(Liquibase・Flyway)。明示的なロールバック SQL と監査証跡がコンプライアンスに直結する。
• Atlas は両陣営を一ツールに収めた。 宣言的の atlas schema apply も、命令的の atlas migrate diff + atlas migrate apply もある。

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 は以下のようなパターンを捕える。

• 大規模テーブルへの無条件 NOT NULL 導入(ロックリスク)。
• 長時間ロックを保持するインデックス作成(CREATE INDEX で CONCURRENTLY 無し)。
• データ損失リスクの変更(カラム drop、型の縮小)。

3.5 Atlas を選ぶべき人

• HCL/Terraform に親しみ、infra-as-code のメンタルモデルに慣れたチーム。
• 複数 DB(Postgres・MySQL・MariaDB・SQLite・MS SQL・一部 ClickHouse)を一ツールで。
• 複数環境(staging・prod)・複数インスタンスでドリフト検出が必要なチーム。
• ORM とは独立して DB のスキーマの真実をコードに置きたいチーム。

4章 · Bytebase — レビューワークフローを第一級市民に

4.1 何が違うか

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

開発者 → 変更提案(PR ライクな Issue)→ SQL Review(自動 + 人)
       → DBA 承認 → 段階的環境適用(dev → staging → prod)
       → 自動バックアップ・ロールバックスクリプト保存

• 複数 DB:MySQL・Postgres・TiDB・Snowflake・MongoDB・ClickHouse・SQL Server・Oracle・Spanner など 25 種類以上。
• GitOps モード:GitHub/GitLab の PR マージでトリガ。
• 自動 SQL Review:ルールベース(カラム命名・インデックス・長さ制限など)+ 2025 年以降 LLM ベース。

4.2 AI アシスタント(2025〜2026)

Bytebase 3.x から追加。

• 自然言語→SQL:「先週の登録者を日別で見せて」のような要求を SQL に。
• SQL Review:LLM が危険パターン(インデックス無しの join、フルスキャン、ロックリスク)を人より速く捕える。
• 変更影響分析:このマイグレーションが影響を与えるクエリ・ビュー・アプリコードを推定。

このカテゴリでは他のツールはまだ追いついていない。Atlas も独自の AI を付け始めているが、Bytebase が最も成熟している。

4.3 Bytebase を選ぶべき人

• 複数 DB・複数環境・複数チームが共用する大組織。
• DBA が正式に承認・レビューするプロセスが必要なところ(金融・ヘルスケア)。
• GUI 経由で非開発者(データアナリストなど)のアクセスが必要なところ。
• 「このマイグレーション PR を誰がマージしたか」を監査追跡する必要がある場所。

使うべきでない: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 と同期。

• 長所:他のツールを覚えなくていい。SQL をそのまま書く。速い。CI フレンドリ。
• 短所:Postgres 対応は Atlas ほど豊富ではない。enum・partial index・function・trigger 等の一部オブジェクトに差。

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 の変化

• Liquibase 5.x(2025):changelog パースの高速化、新しい reporting CLI。
• Liquibase AI Advisor:Liquibase Hub での LLM ベースレビュー。Atlas Lint・Bytebase Review と同方向。
• PostgreSQL 拡張のサポート拡大:pg_partman・TimescaleDB・pgvector など拡張機能フレンドリな変更タイプ。

6.3 Liquibase を選ぶべき人

• Java・Kotlin バックエンド + Spring Boot。spring-boot-starter-liquibase 一行。
• エンタープライズ・銀行・ヘルスケア — 明示的ロールバックと監査証跡がコンプライアンスの要件。
• Oracle・DB2 を含む複数 DB — Atlas・Bytebase より Oracle・DB2 親和性が高い。
• 変更ログを XML/YAML で持ちたいチーム。

弱点: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 の変化

• Flyway 11.x(2025 年後半):ネイティブコンパイル CLI(GraalVM)、起動が高速。
• polyglot 親和性の拡大:Node・Python 向けの公式 Docker イメージと CI ガイドが整備。
• Flyway Teams/Enterprise の新機能:大規模マイグレーションの dry-run、undo の自動化。

7.2 Flyway を選ぶべき人

• Java・Spring Boot の既定。spring-boot-starter-flyway 一行。
• 「SQL そのまま、ツールは軽く」を好むチーム。
• 単純な単一 DB(主に Postgres・MySQL)運用。

弱点: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

• 長所:ORM のモデル定義がそのままスキーマ。一箇所で見える。シャドウ DB で安全な diff 生成。
• 短所:複雑なオブジェクト(partial index、exclusion constraint、一部 generated column、custom domain)は Prisma モデルでは表現不能 — 生成された migration.sql を手編集する必要。

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

• 長所:ORM と分離された軽量 CLI。生成 SQL は保守的で読みやすい。
• 短所:自動 diff が 100% ではない — カラムリネームは人が補正する必要。一部オブジェクト(enum 変更、複合 PK 変更)で角が立つ。

8.3 ORM マイグレーション vs Atlas/Liquibase

• ORM ツールが最もなめらか — モデルとスキーマが一箇所。
• だが DB が ORM の視野外オブジェクト(extension、materialized view、custom function)を多く使うと、ORM マイグレーションのみでは不足。
• そうしたチームは ORM は read/write 型用にだけ使い、スキーマは Atlas/Liquibase で別運用、というパターンが 2026 年に増えた。

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

ツール統合は始まったばかり。

• Atlas:migrate lint が大規模テーブル変更を警告。実行は依然として外部ツール。
• Bytebase:一部の変更を自動で gh-ost にルーティングするモード(エンタープライズ)。
• 多くのチームは依然として 「Atlas/Liquibase が生成した SQL を人が見て、大きなテーブルなら gh-ost で直接実行」 パターン。

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 命令的

11.2 複数 DB サポート

11.3 レビューワークフロー

11.4 ドリフト検出

11.5 AI 支援(2026)

11.6 オンライン DDL 統合

11.7 ORM 統合のなめらかさ

12章 · チーム別決定フレームワーク

ツール決定の最初はツールの優劣ではなくチームの形だ。

12.1 1〜3 人フルスタックチーム(TS/Next.js)

• Prisma Migrate または Drizzle Kit 単独で十分。
• ORM とマイグレーションがセットなので学習・運用コスト最小。
• シャドウ DB が必要な Prisma の dev ワークフローが負担なら Drizzle Kit。
• 追加セーフティ — Atlas Cloud free tier でドリフト検出だけ付ける程度。

12.2 10〜30 人複数チーム、TS メイン(スタートアップ)

• Drizzle Kit + Atlas(lint + ドリフト検出) の組合せが増えた。
• Bytebase はまだオーバーキル。
• GitOps モード:PR に drizzle-kit generate 結果の SQL が入り、CI で atlas migrate lint。

12.3 50 人以上、複数 DB・複数サービス(mid-stage スタートアップ)

• Bytebase + Atlas または Bytebase + Liquibase。
• 複数 DB サポート・承認ワークフローが必要な段階。
• DBA または platform チームが正式なマイグレーションゲートキーパー。

12.4 Java・Spring Boot 中心のエンタープライズ

• Flyway(単純な変更中心)または Liquibase(ロールバック・監査が重要)。
• 追加で Atlas または Bytebase を複数 DB・ドリフト検出用に乗せるパターンも増えた。

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

• どのマイグレーションツールでも、大規模テーブル変更は gh-ost・pt-osc・pg-osc に分離。
• Bytebase Enterprise の自動ルーティング、または手動実行。
• マイグレーションツールは lint・dry-run で大規模テーブル変更を事前にキャッチし警告すべき。

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

• Bytebase または Liquibase — 最も広いエンジンサポート。
• Atlas も複数 DB だが、Oracle・DB2・Snowflake は Liquibase が成熟。

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 か」の宗教戦争ではない。チームが何を守ろうとしているかの関数だ。

• 小さなチーム、速い反復 — declarative・ORM 統合(Drizzle Kit・Prisma・Atlas)。
• エンタープライズ・監査 — imperative・明示的ロールバック(Liquibase・Flyway)。
• 複数 DB・複数チーム — レビューワークフロー(Bytebase)+ lint(Atlas)。
• 大規模テーブル — マイグレーションツールと別にオンライン DDL ツール(gh-ost・pg-osc)。

2026 年 5 月の風景で最大の変化は二つ。

1. Atlas の台頭 — declarative + lint + ドリフト検出を一ツールにまとめ、シェアを急速に伸ばしている。「Terraform がインフラに対して行ったことを、DB に対して行っている」という評価は誇張ではない。
2. AI 支援がカテゴリに — Bytebase・Liquibase Hub・Atlas すべてが LLM ベースレビュー・自然言語変換を付けた。マイグレーション lint はもはやルールベースだけではない。

決定チェックリスト

• チーム規模は? — 1〜3 人なら ORM マイグレーション、50 人+なら Bytebase。
• 複数 DB・複数環境か? — はいなら Atlas・Bytebase・Liquibase。
• Java/Spring 中心か? — はいなら Flyway・Liquibase。
• 大規模テーブルがあるか? — はいなら、どのツールでも gh-ost・pg-osc 追加。
• ドリフト検出が必要か? — はいなら Atlas Cloud または Bytebase。
• コンプライアンス(監査・ロールバック)が核か? — はいなら Liquibase。
• 学習コスト最小化? — ORM 自身のマイグレーションツール。

アンチパターンまとめ

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

• Atlas — Modern DB Migration
• Atlas GitHub — ariga/atlas
• Atlas Schema Monitoring
• Atlas Migrate Lint
• Bytebase 公式
• Bytebase GitHub
• Bytebase SQL Review Rules
• Skeema — Declarative MySQL/Postgres schema management
• Skeema GitHub
• Liquibase 公式
• Liquibase GitHub
• Flyway 公式
• Flyway GitHub
• Prisma Migrate Documentation
• Drizzle Kit Documentation
• gh-ost — GitHub's online schema migration for MySQL
• pt-online-schema-change — Percona Toolkit
• pg-osc — Postgres online schema change
• pg_repack — Reorganize tables in PostgreSQL
• Sqitch — Sane database change management
• dbmate — Database migration tool
• PostgreSQL Wiki — Locking
• GitHub Engineering — gh-ost: triggerless schema changes