そのPostgresマイグレーションは本当に安全か？
Is your Postgres migration safe or not safe?
Postgresのマイグレーションが本番環境でロックやテーブル書き換えを引き起こさないかを判定するツール「safe-not-safe」が登場。migration.sqlを解析し、add-column-constant-defaultやcreate-index-concurrently、validate-constraintといった各文が安全かどうかを、libpg_query 17（wasm）を使って1文ずつチェックする。起動時のリスクパターンに合致しなければSAFEと表示する仕組みだ。
SAFE— No blocking pattern found. The checked statements avoid the common lock, rewrite, and rollout traps in the launch rule set.
HNでの議論
44- orf
こうしたルールベースのマイグレーション安全性チェックは単純だが、決して完全ではない。
問題は、マイグレーションの安全性の一部がデータベースの状態に依存しており、それはDDL文だけでは表現されないことだ。例えば、カラムの型を変更する場合、元のカラムの型によって、何もしないか、排他ロックされたテーブルの書き換えが発生するかが変わる。
他にも、変更するカラムが外部キーである場合に複数のテーブルがロックされるなど、落とし穴がある。
数年前に深みにはまり、与えられたマイグレーションを実際のスキーマに対してイントロスペクションし、Postgresに実際に何をしているかを教えてもらうシステム[1]を作った[2]。
このための組み込みサポートがもっと充実していると素晴らしい（DDL文に対するEXPLAIN？）が、この方向性は静的なルールセットよりも安全で正確に感じる。
安全性は、変更されるテーブルのサイズやアクティビティにも依存する（つまり、空のテーブルを書き換えるのは問題ない）。データベースが実行するロックとアクションを正確に表現できれば、本番環境のメトリクスと統合して、一連のデータベース全体で実際の安全性を推測ではなく判断できる。
1. https://github.com/orf/locksmith
2. https://github.com/orf/locksmith/blob/f8798c6ee92bfae10d416c...
- fabianlindfors
このようなマイグレーションリンターは有用ではあるが、安心感を与えるには十分ではないと思う。私はここ数年、ゼロダウンタイムのスキーママイグレーションツールをメンテナンスしており、自分自身を撃ち抜くあらゆる方法をカバーしようとしている：https://github.com/fabianlindfors/reshape
これはマイグレーションがデータベースをロックしないことを保証するが、おそらくもっと重要なのは、デプロイ中に新旧両方のスキーマをサポートし、それらの間で自動的にデータを移行することで、アプリケーションのゼロダウンタイムロールアウトも可能にすることだ。また、標準的なSQLコマンドを使う場合には通常複数の別々のデプロイが必要となるバックフィルなども処理する。
- agubelu
スキーマ管理に使っているツール[1]が、ほとんどの追加的なスキーマ変更でマイグレーションの必要性をなくしてくれるので、あまり心配しなくていいのはありがたい。
破壊的な可能性のあるマイグレーションは自動生成を拒否するので、そうした場合は手で書く必要があり、このツールはその際に役立つだろう。しかし、それらは例外であり規則ではないので、より注意深くレビューする。
- vira28
著者です：少し背景を。私はCloudflareでPostgresプラットフォームチーム（2019-23）を率いており、170以上の成長中のプロダクトチームをサポートしていました。常にあった要望の一つがスキーママイグレーションのレビューです。多くのベストプラクティスを公開し、CIチェックを追加しましたが、それでもまだ捉えきれませんでした。また、ロック（書き換え）がどのように機能するかの内部を説明しようとしましたが、ほとんどの開発者はただ答えが欲しいだけだと気づきました - 実行しても安全か安全でないか？
ピンとくるかわかりませんが、名前はSilicon ValleyのJian Yangのホットドッグかホットドッグでないかのアプリへのオマージュです。
また、安全か安全でないかの判断はデータやヒストグラム、エッジケースに大きく依存することは理解していますが、それでも多くの簡単な問題は決定論的なルールエンジンで簡単に捉えられます。そこでpg_savior[1]を移植し、WASMとしてコンパイルされるlibpg-query-node[2]のSQLパーサーを使いました。これで完全にブラウザ上で動作します。テレメトリなし、ログインなし。ソース添付[3]
[1] https://github.com/viggy28/pg_savior
- nijave
Ruby用のhttps://github.com/ankane/strong_migrationsもある
チェックと説明はかなりシンプルでわかりやすいので、ライブラリを使っているかどうかに関わらず、良い参考資料にもなる