I like how Symfony does it in PHP:

Config files have well known locations (e.g., <project root>/config for main project, and <plugin root>/Resources/config for plugins) for config files. The main config is loaded into memory, and then each plugin config is loaded and merged into the main config.

This has several advantages:

1. Each path allows for auto-discovery of new config files
2. The config files can be in any file format that the app supports read (e.g., .ini, .yaml, . php, etc)
3. The plugin config can overwrite anything in the main config
4. Environment-specific configs can be loaded based on a $ENV variable (e.g., dev or test), or by ignoring files in your VCS

For Symfony, it is more complicated than that in that they also have mechanisms to define valid configuration values and their expected types, but that’s beyond the scope of your question.

Database configuration is an interesting choice. It certainly would help with scaling across multiple servers. Of course there is still a need for local configuration to access the database, but how often does that really change? But if you don’t need to scale more than two or three servers, it might be a bit of overkill IMO.