
Можно по різному, але +- простий безпечний піхід для звичайної бази може бути такий.
1. Просто але з повним даунтаймом, тобто не приймаємо нові інсерти від юзерів.
- Міграція створює нову колонку і одразу робить її бекфіл через insert from select.
- Знімаємо даунтайм після деплой нової версії
2. Без дауннтайму трохи складніше але не неможливо
- така сама міграція з бекфілом
- далі обслуговуєте на рівні коду запис в дві колоники, з читанням з нової з фаллбеком на стару, аж переконаємось що все ок
- в наступній версії - робимо повний перехід на нову + потрібні дропи
Наголовніше не забувати про можливий роллбек, бо це 90% відвовідей на всі кейси.
сам підхід і краще розумення BC варто трохи запозичити від Stripe API, які можна теж поширити на схему бази.
- docs.stripe.com/upgrades
- youtube.com/watch?v=tgDAFu…
- теж цікаво в контексті ролбеків "no down migration" freek.dev/2900-why-i-don…

YouTube
Українська






















