In it's simplest incarnation, yes it could be just a single DB table with boolean flags.

However there are a lot of connected needs that most real world-usages run into:

- Per-user toggles of configuration values

- Per-user dynamic evaluation based on a set of rules

- Change history, to see what the flag value was at time of an incident

- A/B testing of features and associated setting of tracking parameters

- Should be controllable by e.g. a marketing/product manager and not only software engineers

That can quickly grow into something where it's a lot easier to reach for an existing well thought out solutions rather than trying to home-grow it.

If you have a single database than maybe you can (and should?) just start with a basic, single table approach, but as you grow in size and complexity FF management can become a challenge, with reporting gaps and feature release management. I usually see two charateristics with the former approach: growth in the # of FFs over time and a messy Excel report for what they are, do and if anyone still hits the old code. This might be fine for a while, or forever, but often gets painful.

Clearly you haven't worked at an org that uses something like this extensively (LaunchDarkly for example.)