Pros and cons of different feature flags table designs published 1/2/2020 | 4 min read

Feature toggles (or feature flags) are a common practice in software development, it comes to the scene when business requires full control over your application features, so it's easy to turn on/off a feature at any time.

Welcome everyone to a new story on devspedia. Today I'll discuss two methods used to design feature flags (we've discussed feature flags previously in "Here's how you can start using feature flags today"). We'll assume we have two scenarios related to GitHub:

1. First scenario: PR-related features with vertical feature flags table design.
2. Second scenario: Same as 1st scenario but with horizontal feature flags table design.

First scenario: Vertical

The above table shows a simple feature flags table with 3 columns:

• id: Auto increment
• code: unique string to identify a particular feature.
• is_enabled: a boolean that tells whether this feature is ON or OFF.

This way we can easily scale the number of feature flags, and even add extra optional columns if we'd like to attach more details tied to a particular feature, for example we can add review_count column with value 2 which can imply 2 reviews are required for require_review flag. Let's see pros and cons of this implementation.

Pros

1. Easy to scale and manage, each feature lives in it's own row.
2. Easy to attach extra info/columns to feature flags.
3. Can easily group feature flags for each group of users, so adding column premium for example as a bool, this means the feature is only applicable to premium subscribers.
4. Recommended for both simpler and more complex apps, with few to many ON/OFF toggles.

Cons

1. Adding extra columns means so many empty/null cells for all rows that are not using this column.

Second scenario: Horizontal

The above horizontal example, assume each feature flag is a column (vs. row in prev. example). And that we'll only have one record/row (or more and differentiated with another column, ex: user_group) which we can query as select * from feature_flags; or select *from feature_flags where user_group = ....

Pros

1. Your query will return an easier to consume results: require_review: true.
2. Simple design, easy to maintain.
3. Recommended for simpler apps, with few ON/OFF toggles.

Cons

1. Can easily becomes a mess to maintain when you start adding extra non-feature flags columns.
2. Not suitable for larger scale apps with groups of features.

it's always a good idea to take some time and think of the better and most suitable design for the type and size of your app before implementing feature flags.

That's all for today's story. Thanks for reading devspedia, I love you, and I'll see you the next time :)

You may also like reading: