Using Databases for Configuration Values

What is it and why would it ever be useful?

The idea of storing configuration values in a database has been around for years.  The main appeal to it has always been the flexibility and ease of managing configurations in production environments.  E.g.  Simply connect to the database and change the value.

It is very appealing to have a large degree of control of an application after it has been launched to production without having to do the standard tear-down, update the configuration file then relaunch / remote into the production machine, change the config then restart the service.

Where not to use it?

For small applications  without requiring fine grained control whilst in production, this type of configuration management can be needlessly complex and near useless.  Not only are small applications typically quick to deploy to production, they don’t usually have much that needs configuring.

Where would you use it?

This type of configuration management would most effectively be used in the larger applications where deployment/modification to production machine files is painstaking.

An example of where it can be used in an a large web application would be for something like a feature toggle.  So for example, you are perhaps you have just launched a new feature to allow Administrators to import users from a CSV file, however there’s a bug that breaks your application.  As a temporary fix for the broken import it might be a good idea to turn off the Import feature using the database configuration until a solution has been implemented and is ready to be deployed.  This can help minimise downtime.

Another good example would be for features that might require a gradual roll-out.  So perhaps you’ve made a new feature for “User Profile Management”, you may decide that you want this feature to only be available for one or two production tenants (customers) in case there are any problems.  With a tenant specific Feature Toggle you can safely turn the feature on for only the tenants you want just by changing the values in the database.  Later, when you realise it’s working perfectly you can turn the rest of them on without redeploying or having to remote into multiple production machines.

How to implement it?

An example of how to implement this kind of this is available on my repository here.  The example is with Amazon SimpleDb and provides PowerShell scripts for updating the database configs as well as the normal Web.config for the Amazon Keys.

Leave a Reply