Since you're specifically asking about those two options I won't go deeply into the 12factor pattern  which states:
An app’s config is everything that is likely to vary between deploys. [...] Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code. [...] Another approach to config is the use of config files which are not checked into revision control.
The twelve-factor app stores config in environment variables.
Short answer: If the config, by it's nature can change at runtime, e.g. on a per-user level (so if it's actually a feature of your product like
change background color), then put it in the database. If it's integral for your code to work, like database connections, api keys etc. there is no need to accept the overhead of storing it into a another system (which your DB is).
Whilst you can put it in config files, you're life will be better when storing it in env variables. That way it's easy to adjust your code for multiple environments. It's also a good practice not to put sensitive information into version control.