RDBMS 最困難的事情都圍繞在「怎麼不中斷服務」(很多事情在不用考慮 uptime/downtime 的前提下很好做，不論是 ALTER 或是 failover，到備份還原計畫)，而 PayPal 的 Braintree 在「PostgreSQL at Scale: Database Schema Changes Without Downtime」這邊討論修改 PostgreSQL 的 database schema 時怎麼不中斷服務。
文章內的大部份都是給 DBA 知道的細節 (e.g. 怎麼樣才不會觸發大規模的 lock 導致服務中斷)，而不是開發者面向的事情... 但開頭的部份，也是我認為最重要的部份，則是需要 Developer 參與的：
For all code and database changes, we require that:
- Live code and schemas be forward-compatible with updated code and schemas: this allows us to roll out deploys gradually across a fleet of application servers and database clusters.
- New code and schemas be backward-compatible with live code and schemas: this allows us to roll back any change to the previous version in the event of unexpected errors.
為了符合這兩個要素，可能會在 schema 設計上有好幾個階段的操作，而非一次到位。而且也才能避免要關站從 backup 倒資料回來的情況...
建議可以研究看看要怎麼玩，常見的情境知道怎麼設計步驟後，真的遇到的時候會比較熟練。
