I've designed such a "classic mistake".

> In addition, it doesn't give you various features such as tagetting by users, segments, etc. Nor does it give you things like progressive rollout or automated rollback (yes we were using that in house and had saved us at least a few times).

These are things you can think of quite easily, or you just survey the landscape of what challenges other implementations run into and they inform you of this. The first iteration of our design had all of those; we could target users, always-subscribe internal users, we could have two features have the same segment/ordering of rollout, etc.

Database load wasn't ever a problem, because you're talking about quite literally a single SELECT on an already established & otherwise in use DB connection. But caching is not that much to bolt on afterwards should it become an issue.

It's never been clear to me that the simplicity of understanding that a single query has, even if it might be short a few features, is outweighed by the complexity of a full dependency to an external service.

As it was, our FF system outlived the company, and was sunset when the company ended.