[meta] Add database driver for MongoDB to Core as experimental

catch → credited alexpott → .

catch → credited lauriii → .

catch → credited longwave → .

Adding a note about listing queries to the issue summary since that's also a severe performance/scalability issue now that mongodb can significantly help with especially with large datasets.

For views, at devdays we discussed adding an entity query views backend, and converting all core (and starshot once it has them) shipped views to use it. An entity query view will be interoperable between mongodb and relational database drivers. Some previous work/discussion is in https://www.drupal.org/project/efq_views → and ✨ Entity Query views backend Active .

I think we could add mongodb as alpha/beta to core without resolving the views issue, but would need to fix it to make mongodb stable. However an entity query backend for views has a lot of positives in its own right, not just for mongodb.

I've discussed the idea with @daffie and @catch in detail at DrupalCon Lille and Drupal Dev Days and on a high level the proposal is fine. Adding a new database driver is not part of the strategic focus for the team at the moment, which may lead into some delays with reviews in cases where there's higher priority work waiting for feedback from committers.

I'm leaving the tag on because I'd like to be involved in the process again when we have a better sense on what's the impact on UX (such as Views) and the ecosystem.

The main problem for why Drupal is slow is, because of getting entity data out of the database is slow.

Is that statement backed by any performance numbers / benchmarks?

What I've often seen as a performance bottleneck is not the database itself, but the connection to it. When a Drupal site grows (showing in its number of configuration items), one request to a Drupal page may take up hundreds, sometimes over one thousand of database queries. This is because of cache tag lookups, config reads and finally when content entities are queried. When having a local database without any latency, performance is usually not a problem.

@mxhcache tag lookups can be replaced with redis so they won't hit the database at all.

On a site with lots of data, entity listing queries can individually take a very long time - anything from hundreds of milliseconds to dozens of seconds for a single query if it has conditions and sorts on different database tables.

It's less that it's the main reason that Drupal is slow, since sites with much less data have different performance issue, and more that it's one of the hardest issues to address.

@mxhcache tag lookups can be replaced with redis so they won't hit the database at all.

Thanks for the reply and tip @catch using Redis might actually an option to try out. My key point in #9 is that it doesn't make sense to replace a Porsche with a Ferrari for getting faster when the speed limit is at 50 on a one-lane bridge. I'm sorry that I might have brought in something off-top here - will move it into a separate issue in case there's more room for discussion on it.