We should considering deprecating/reducing use of/removing DBTNG in Backdrop to accomplish the following goals: - Improve performance by removing abstraction around constructing queries. - Improve learnability by avoiding a Drupal-specific abstraction layer and syntax.

This introduces a need for substitutes in a number of places however: - Alterability: Remove the ability to alter queries. No more alterableQueries or db_rewrite_sql(). Instead, any query that needs to be altered instead utilizes a View, that can be altered to affect the query. Or, avoid altering entirely through... - Access control: Make access control queries explicitly defined when creating Views. Instead of automatically restricting listings, require listings to have access control explicitly defined (similar to explicitly defining the "published" state). - Database connections: We can still use PDO to connect to the database. It's just as fast as a mysqli connection in benchmarks, and makes it so we can use a consistent syntax for doing queries, regardless of the back end.

Things we would NOT remove or build out later include: - Schema API: As long as we support PostgreSQL (which we should for the initial release at least), Schema API is still needed to define and update tables. - Entity abstraction: We should focus on ensuring entities are loaded and modified through the entity API alone, making it so it's still possible to cache and store entities in a swappable mechanism. Although things like MongoDB are probably not the target audience, efficient per-entity caching definitely is, so this benefits us for the time being.

The initial effort should be to provide a database system that can update usage of db_query() throughout core with a lightweight replacement directly against PDO. We can work on removing db_select/update/insert/delete queries over time and then remove them (and DBTNG) when finished.

GitHub Issue #: 
61