In Drupal 9.4 the database drivers for MySQL, MariaDB, PostgreSQL and SQLite were moved to their own modules. This session is about why we did that and what we want to do next.

We had a number of problems with the old situation:

1. Having contributed modules with a database driver copy their driver files to the directory drupal_root/drivers is not very composer friendly.

2. The database driver classes are unfortunately not enough to make Drupal work for a specific database. All database drivers need to override things like (views and other) plugins and entity storage classes. Those overrides need to live in a module

3. Tests are not always the same for every database driver. Those overrides also need to live in a module.

4. The by Drupal core supported database drivers are the example for contributed database drivers. Just like the Drupal core module and themes are the example for the contributed module and themes.

5. Database drivers should be able to extend another database driver. Just like modules can do.

Having the by Drupal core supported database drivers in their own modules makes it possible to do:

A. Create a new database driver for MySQL that allows queries to be run asynchronously. For instance with multiple blocks on a page, the block data can be loaded in parallel from the database instead of synchronously. PHP 8.1 has added the Fibers functionality and that allows I/O and database queries to run asynchronously. The database driver for MySQLi allows Drupal to use asynchronous queries.

B. Store content entity data in a document format. Content entity data is now stored in multiple tables and with a high number of entities, getting entity data out of the database will become slow. When used in combination with authenticated users and a lot of content, will result in Drupal becoming slow. Storing content entity data in a document format will make it fast again. The only database that a the moment has enough functionality to make it work with Drupal is MongoDB.
Using caching is great, but has it limitations. If we make hard Drupal calls a lot faster, we can use Drupal without any caching or with a lot less. PHP is fast enough for this. Databases are fast too. Only storing data following the relational database rules makes will result in complicated queries for getting the data out of the database. Complicated queries with large amounts of data will result in a performance nightmare. That is why we are using so much caching with Drupal sites. For anonymous users this is not a problem, only with authenticated users is caching a lot of times not possible. The solution is to store content entity data in a document format. In that way we almost always can get the data out of the database with a simple query (and therefor a fast query). When all queries are simple queries, the resulting Drupal page call will be fast.

I have already build a database driver for MongoDB. The driver is in the form of a Drupal module and the project can be found here: https://gitlab.com/daffie/mongodb867. It is based on Drupal 8.6.7 it hacks Drupal core with a >1.5 MB patch file. This is totally not maintainable. To fix that problem I have started to work on Drupal core to make the MongoDB database driver module work without patching/hacking Drupal core.

I would like to end with a group discussion about what we want to do next. What does the group think. Do they have other/new ideas. Hopefully get other people involved in what is next. This can also happen after the official session.

I am the main contributor in having the database drivers moved to their own modules, I am also the subsystem maintainer for the Database API and I have over 500 Drupal core commit credits.
Session (20 minutes)

Experience level of the audience

Intermediate