I have looked at the source code, briefly, and the problem is that the module is a complex "beast" that relies heavily on the core's API which I am not currently familiar with.

I have a kind of pieced together on how Drupal assembles a completed node object by traversing the various tables (node, node_type, field_config, field_config_instance, etc).

What confuses me is the data abstraction layer. field_config has a storage_type which appears to indicate whether a field is stored in SQL or not.

From what I have read and interpreted, Drupal is flexible enough to have a system which is data store agnostic, so if I had a products content type and capacity out-grew what MySQL was capable of, I could (in theory) switch to MongoDB or similar DBMS which allows better scaling.

  1. So, how would I attach a field to a content type, which let's say was stored in Mongo, but the remaining fields stayed in SQL?

  2. More interesting, how does VIEWS deal with this disconnection in data storage? If I store some fields for a given type in MongoDB and some in SQL how does VIEWS handle the JOINS and filtering capability?

  • 1
    As far as I know field storage has to be set globally, not per field. If you use mongo you can say goodbye to relationships in views, as mongo doesn't support them in the same way. I'm pretty sure this should answer your question fully: drupal.stackexchange.com/questions/84883/…
    – Clive
    May 7, 2014 at 13:33
  • So the implicit JOINS D7 performs between node A and node B would not be possible if Mongo was used? I figured as much, and if they do, I am very curious to know how it's done...Still confusing me though, why would D7 store the field type on a per field basis if its supported only globally? I can only assume this is a future spec they are looking into?? Thanks again - your always a help :) May 7, 2014 at 13:37
  • 1
    As I understand it you'd be able to get entity/field data into there using the EFQ Views module, but it does limit things (you couldn't link the node author entity through to a node-based view, for example). I'm not sure why that flag is per-field to be honest, I'd probably go with your suspicion that it was for future work, but then everything changed in D8 so it hasn't been continued. Always happy to help, this is also a very interesting question :)
    – Clive
    May 7, 2014 at 13:40

1 Answer 1


As it currently stands it is not possible for Drupal to run a pure MongoDB installation with Drupal. Drupal has made a lot of progress towards abstracting out database connectivity into a central model layer with Drupal 7 and Drupal 8 promises even more. However it is still a work in progress and while a majority of the functionality is available as MongoDB backend, as it stands today a few of the components remain dependant on SQL.

As most of the work to port Drupal to MongoDB has been towards scalability and performance, it is possible to have a site where public page views are 100% on MongoDB. Performance benchmarks on a MongoDB backed Drupal instance are quite impressive.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.