I am working on a module where I need to save thousands or I guess millions of data (product'data from various e-commerce sites). So I am not sure of saving that data in a custom table by using custom entity or should I save that data in nodes?

As for searching, a user can use elastic or search_api_solr and use views for displaying the data, so is it better to use custom row or nodes to save that much of data?

  • 1
    There is no difference between “node” and “custom entity” especially if you extend it from ContentEntityBase. Node is a content entity shipped with core providing content publishing on top of it, with various modules integrating with it (and hooks, etc). You can have a million nodes, you can have a million custom entities, the result is the same. It’s all in how you want to manage and develop it. – Kevin Jun 10 at 16:06
  • always use custom entity. nodes are only for people that want to use drupal and not develop anything. – user21641 Jun 11 at 12:41
  • I suppose. I was giving the pc explanation. – Kevin Jun 11 at 13:42
up vote 4 down vote accepted

I actually disagree with the comment from @Kevin, using or not using nodes can make a huge performance difference, for multiple reasons.

Yes, node is a pretty standard content entity, but..

  • It is revisionable
  • It is translatable
  • It has a bunch of standard base fields like promote, sticky that are likely not relevant for your use case
  • Any data that actually is relevant needs to be stored in configurable fields, which results in additional tables.

So if you need 20 additional fields to store stuff, you end up with 4 base tables and 40 additional tables, so 44 tables in total.

If you don't need revisions and translations and assuming you only have single-value fields, you can do that with a single table instead with a custom entity type and base fields. If you need revisions then it's 2. And each multi-value field does require 2 additional tables but usually there are not that many of those.

With millions of records, it's definitely worth thinking about if creating a custom entity type is worth it and sounds like for that case, the answer is probably yes.

It's worth pointing out that there's still a decent amount of modules (even in core), that currently only work with nodes, e.g. book or diff. So make sure that you don't need any of that or be prepared to re-implement that functionality.

It depends. As Kevin pointed out, there are not much difference as "entities". However: using a custom entity CAN be a big advantage in some cases.

Since nodes are being used in the most cases too many contrib and core modules can integrate with it, which can lead to unnecessary overhead.

When going for custom entity maybe you have to do some initial extra work for it, but then it is in your hands: it's much easier to make custom changes for it. Also can make your code easier to read.

So final conclusion: If you use already a couple of node bundles and your new type will need a special highlight I would go for a custom content entity.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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