The use of feature flags in software development has become more and more prevalent over time, especially as teams move to DevOps-style development with frequent releases. I've often thought that using feature flags allows technical people to separate out the deployment of some feature or change from the release of that to users. There are a number of articles on this style of work (feature flag driven development, Why Use Feature Flags?) as well as a discussion at Reddit.

I am a big believer in feature flags helping with improving your software in many ways. These articles (and others) highlight the advantages that a software organization gains by using feature flags. Failed releases become less of an issue, as the specific change that doesn't work can be turned off. This can even work with databases. I can deploy a database change and at a later time have the code (or new table/column) start being used when a feature flag is set. If there is an issue, I can turn off the feature flag and stop using the code (or populating the schema). I can then clean things up, even saving data before I make a change.

I don't love the idea of using feature flags to handle security access to features, which is pointed out in a few places. If this is for testing or evaluation by customers, perhaps. If this is to get access to data from a security standpoint, this is a bad idea. I hope most of you are savvy enough to realize this.

Feature flags are not a panacea for preventing issues. They do clutter up code and make it harder to read. Once a feature is done and permanently enabled, the code for switching flags should be removed. It is also hard to stack versions of features up behind one flag, which can increase coding mistakes. Adding flags in stored procedures or functions also can wreak havoc on query optimizers, so I'd recommend you don't do that. Instead handle feature enablement in the application code and use multiple procs/functions for the different functionality you might need.

To use feature flags appropriately with database changes, you also need to be able to dark deploy those changes, with your application code able to handle additive changes to the database. A new column, a new table, or a new parameter should be easy to add without breaking the app code. This requires the use of defaults as well as good coding practices (no select *, inserts with column lists), but it can be done. Once you are in this place, life becomes a lot less stressful and feature flags work amazingly well.