Are configurations written and read directly to/from .yaml files or still to the database?

Question

Background

Drupal 7 and previous versions have attracted criticism for Drupal web site admin configuration being stored in the MySQL database, the criticism being that being in a database means that it cannot be directly managed in git together with the PHP code based development for a Drupal site (custom modules, themes etc.).

Secondly with configuration being in the database along with content, transporting configuration between development, test, staging and live servers as part of development activity is complicated, though Features module (and related) can help.

Reading through: https://www.drupal.org/documentation/administer/config

...I'm getting the impression that, in Drupal 8, the database is still used to store the config, when for example a site builder creates a new content type, rather than this being written to a .yaml file which is used directly.

So actually it seems that the role of the yaml file(s) is a much more purer (than Features) vehicle for the configuration. Whereas with Features it was PHP code which was harder to read what the configuration was, including if doing diffs between commits where config had been updated resulting in a new version of the Features-based config export. By that I mean not that PHP itself is hard to read, as I'm familiar enough with it, having written custom modules, hooks, themes. What I mean is that to express a configuration in PHP is perhaps not the most legible way to do it. So I can see the rationale of using yaml. The difference is that yaml will be read by a parser to apply a config. The complexity of applying the config is in the parser, which most folks need not concern themselves with most of the time, so the yaml can more cleanly describe the config. whereas in Features, there is no parser / yaml (or other script) separation. The descripton of the config and the means to apply it are necessarily in the same place as PHP code which is executed directly, so it's bound to be a bit harder to read the config, particularly if doing git commit diffs.

So there's the rationale for yaml, a Declarative Programming approach to storing configuration management in Git, contrasted with Features which is an Imperative Programming approach. And next what I need to know is this the case that Drupal 8 does still store config in the database does still and yaml files are the means for transporting config (replacing what Features did in D7 and before)?

(By the way I am a big fan of Drupal and spend most of my time at work, working with it for the sites that my organisation produces and maintained and am also involved in the community. So this question is not a stealth campaign against Drupal in favour of other platforms. It is a genuine question to try to dispel the apparent mystique around Drupal 8 and the new config management system)

Update @Berdir's answer (accepted) is a great definitive summary as to the state of Drupal 8 regarding configuration management.

I recently discovered that using yaml for config in Drupal 8 is a concept that has been developed for Drupal 7 with the Patterns module, also read a FAQ on it which includes comparing features.

Update

Change default active config from file storage to DB storage Is a definitive answer about making config active from DB storage, which corroborates with @Berdir's answer.

Answer 1

Yes and no. (I am not sure if this will be too technical).

The configuration is stored in configuration objects. Drupal has by default an active and a staging storage for those configuration objects.

The default active storage is in the database, yes, for performance and easier backup/restore, among other reasons. But that is an implementation detail. It used to be read directly from files, but that was pretty slow, even with caching.

The staging storage is yaml files in the staging folder in your file system. Those are the files you manage in git.

You can export to staging and import again from staging through the click of a button in the UI or with drush. Unlike Features in Drupal 7, which uses custom processing to transform configuration between feature files and the actual drupal site, the configuration object structure is always the same. Serialized to yaml for the file storage, as serialized php arrays in the database storage. Drupal does not care (for the most part, but that is too technical). If you want to, you could write a configuration storage that stores it encoded in pictures, as long as Drupal can get the standardized array structure out of it again that it put into the storage.

So, yes, the configuration is by default still stored in the database, but not in the way you were used to in Drupal 7.