I won’t say that feature flagging your database migration will make everything easy, but it will make it easier to test it with real, live data (for a subset of your user base), and much easier to roll it back if something goes wrong. I will explain how you can use feature flags to gradually apply a database migration or schema change, while constantly verifying that the new model passes integrity checks. This ensures that the migration can be applied in a controlled manner, with very little risk.

1. Feature Flagging
to Reduce Risk in
Database Migrations
By Patrick Kaeding
Lead Engineer at LaunchDarkly
@pkaeding @launchdarkly

2. About Me & LaunchDarkly
• Current: Lead Engineer at LaunchDarkly
• Past: Engineer at Atlassian
• LaunchDarkly is a cloud-based feature flag management
platform
• Separate deploying code from releasing features
• Manage risk of releasing features
• Measure impact (both KPI and Ops performance)
@pkaeding @launchdarkly

3. Database Migrations
• Sooner or later, it is inevitable
• Schema changes
• Moving to larger database cluster
• Moving from one kind of DB to another
@pkaeding @launchdarkly

4. Maintenance window
Database Migrations (Bad Old Days)
Application Old Database
@pkaeding @launchdarkly

5. Database Migrations (Bad Old Days)
Old Database New Database
Migrate
Maintenance window (application offline)
@pkaeding @launchdarkly

6. Maintenance window
Database Migrations (Bad Old Days)
Application New Database
@pkaeding @launchdarkly

7. Maintenance Window Approach
• Pros
 Simplicity
 Can always be used (since both code paths don’t need to
work at the same time)
• Cons
 Downtime
 If there is a problem, redeploy old code and restore from
backup
 All or nothing
@pkaeding @launchdarkly

8. Zero-Downtime Approach
Database Migrations (The Less Bad Days)
Application Old Database
Write
Read
@pkaeding @launchdarkly

9. Zero-Downtime Approach
Database Migrations (The Less Bad Days)
Application Old Database
Write
Read
New Database
@pkaeding @launchdarkly

10. Zero-Downtime Approach
Database Migrations (The Less Bad Days)
Application New Database
Write
Read
@pkaeding @launchdarkly

11. Zero-Downtime Approach
• Pros
 No downtime
 If there is a problem, you can keep running from the old
database/schema
• Cons
 All or nothing
@pkaeding @launchdarkly

12. The Feature-Flagged Approach
Database Migrations (Modern Times)
Application Old Database
Write
Read
@pkaeding @launchdarkly

13. Feature-Flagged Approach
Database Migrations (Modern Times)
Application Old Database
Write 100%
Read 100%
New Database
@pkaeding @launchdarkly

14. Feature-Flagged Approach
Database Migrations (Modern Times)
Application Old Database
Write 100%
Read 100%
New Database
@pkaeding @launchdarkly

15. Feature-Flagged Approach
Database Migrations (Modern Times)
Application Old Database
Write 100%
Read 100%
New Database
@pkaeding @launchdarkly

16. Feature-Flagged Approach
Database Migrations (Modern Times)
Application Old Database
Write 100%
Read 100%
New Database
@pkaeding @launchdarkly

17. The Feature-Flagged Approach
Database Migrations (Modern Times)
Application New Database
Write
Read
@pkaeding @launchdarkly

18. Feature-Flagged Approach
• Pros
 No downtime
 Gradual rollout allows you to monitor
 You can roll back just as easily (or partially roll back)
 Compare results with live data
• Cons
 Longer period for both databases to be operational
@pkaeding @launchdarkly

19. Demonstration
@pkaeding @launchdarkly

20. What about…
• Schema changes? New fields? Restructured data?
• Which users get the new DB?
• Open source alternatives?
@pkaeding @launchdarkly

21. Questions
• pkaeding@launchdarkly.com
• @pkaeding
• @launchdarkly
• https://launchdarkly.com
• Blog article: http://kaed.in/db-blog
• Demo code: http://kaed.in/dbcode
@pkaeding @launchdarkly