Problem:
Drupal 6 was strongly tied to MySQL and its table format. Drupal 7 introduced the concept of Entities and Fields. Now comes Drupal 8, and it needs a new Copernican Revolution: switching to storing and managing generic semi-structured "documents".

We need to review the state of the art in this domain and discuss implementation options. The objective is to solve some of our current pain points:

A single API can store both content and configuration (because they are the same)
The API can have built-in synchronization options to easily push both content and configuration between environments
The API can improve our scalability by materializing some of our queries (... and removing the need for the two manual denormalizations we have in Drupal 7 core: tracker and taxonomy)
Proposed solution:
We will discuss the idea of implementing a Document-oriented API in Drupal 8. The potential features of the API could be:

Stores document as-is, without transformation
Can perform queries deep inside the documents (à la MongoDB), including across relationships; and can also materialize them (ie. save the result set and maintain it across time)
Revisions everything and addresses content by their revision IDs (à la Git)
Supports mixed storage, allowing querying across several storages (including local filesystem storage, database storage, remote storage, etc.)
Can leverage both standard SQL (via DBTNG) and proper document-oriented database engines (MongoDB, CouchDB, ...)