Now that we have a fairly good idea how Drupal 8 and data looks let's discuss what can MongoDB provide and why would you want to run it. In Drupal 8, every kind of data can be stored independently. I fully expect that people will indeed mix storages. For example, D8 by default runs a config query on every page to find the blocks to be displayed for the current theme. Again, by default, config entities are stored as serialized PHP arrays so the only way a query like that can run is to load every single block entity from the database and iterate over them.

Perhaps the most important development is the final naming of what was field/field instance in Drupal 7: in Drupal 8 these are configuration entities. The machine names are field_storage_config and field_config. There has been several renames but we have settled on these finally (although the field_config rename is not yet in). It does reflect the most important difference between them: field storage contains everything pertaining to the storage of the field. The things that do not change the storage of it go into the instance.

The standard mechanism for backend-aware service overrides is in and these services are already tagged. We have agreed on how to transfer data from one backend to another and my sandbox contains the first getTransferIterator implementation for config with more to follow.

There hasn't been an update for some time now; things have quieted down a bit, I am mostly just writing drivers now (and coach people on migrate). MongoDB module caught up with the latest config changes and so the module works again. Migrate bugfixing moves along steadily with more and more people actually trying it and fixing bugs, hurray!

At DrupalDevDays Szeged, skipyT, fgm and myself made tremendous progress with writing the MongoDB drivers. All the override mechanisms work as expected and things in general, work. Most importantly, we have an entity storage backend and a significant percentage of the entity storage query tests pass (it is not expected all ever would pass, for example relationships are not supported).

Migrate in core works. Yesterday, after our weekly call (I am so thankful for eliza411 for organizing these calls, they are absolutely invaluable) a clear roadmap have emerged and I have written a rudimentary but functional drush command to run our migrations. Then I pointed it to a Drupal 6 database... and it worked. Just like that. Today penyaskito has finished the aggregator feed migration that eliza411 and mpgeek started and also written the aggregator item migration. These also work.

Drupal 8 Alpha 6 is out and it has a migrate module in there! It even has a few complete migrations: variables to the configuration files owned by system module. Since the last report the configuration of process has changed significantly, this is now documented in the handbook. We have two patches in the core queue, one potpourri of small fixes and one to split migrate into migrate and migrate_drupal, the latter holding the Drupal 6->Drupal 8 and Drupal 7->Drupal 8 migration.

berdir unified the DatabaseStorageController and the DatabaseStorageController classes. I have been working on migrate, this reports is at https://groups.drupal.org/node/357993

Done: thanks to the 18 months long work of swentel and yched (assisted by xjm, larowlan, alexpott and tim.plunkett) field_config and field_config_instance tables are dead and we are using CMI! Not a lot of tables left.

First, a briefing of already committed patches: Image toolkits, aggregator processors and parsers are now plugins. The form storage is now in key-value instead of abusing the cache system. Twig is now available during install, unlocking much of the conversion -- this needs your help. Alex Pott has been named branch maintainer which will make the whole commit process much, much faster.