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:

...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.


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.

up vote 10 down vote accepted

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.

  • +1 Thanks @Berdir - it answers my key question about use of the database. The other details are interesting too, I'll read through again in the morning, Monday day time / next day or 2, to develop an understanding of those and follow up. Thank you! :) – therobyouknow Jan 19 '15 at 1:07
  • Really nice summary, @berdir! – penyaskito Jan 20 '15 at 22:00
  • 1
    MongoDB can store the config objects without serializing and so querying them (for example blocks) is much faster. – user49 Jan 21 '15 at 5:03
  • I would guess the other reasons for using the db would be all the general features you get with a db, like locking (which could be useful to prevent inconsistencies with multiple users editing the same place on the site) as well as replication. – therobyouknow Jan 23 '15 at 9:29
  • 1
    To further support @Berdir's great answer with further thoughts: to add to the performance reasons of using a db rather than file based is that I would imagine the Yaml parser is deliberately not designed for the demands of access to the yaml files in a high traffic real time environment. In other words, MySQL (et al) databases are actually very good for this sort of thing, a mature, proven system. Yaml parser more suited to much less frequent, non-production usage of batch-like processing for deployment. Not that they couldn't be improved on for certain usage though (mongo etc). – therobyouknow Feb 1 '15 at 19:30

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.