Is there any rule when to use a new field in the user account for storing information and when to use the user.data service?

My initial approach was: When the information should be editable either by an administrator or by the user itself, then use a new field. When the information should not be editable, only by code, use user.data service or a custom table.

E.g. in my case I am storing some information about where the user came from (marketing campaign) and some other information gathered during registration. This information is not meant to be shown to the user or edit by the user. Thus I decided to use the user.data service.

Now I am experiencing a very fast growth of the user_data table and I'm wondering whether my approach was correct. Maybe I should have created a new table for this or use a new field in the account.

Is there any rule when to use the user.data service and any limitations?

3 Answers 3


The purpose of the UserData API is to allow the storage of certain pieces of information related to a particular user. Its concept is similar to the State API in that the type of information stored is not a configuration that should be exported. In other words, it is specific to the current environment (but belonging to a given user rather than a system or subsystem).

Users are content entities, who can have fields of various data types. These fields are typically used for structured information pertaining to the user, for example, a first and a last name. However, if you need to store something more irregular, such as user preferences or flag that a given user has done something, the UserData is a good place to do that. This is because the information is either not something structured or is not meant for the users themselves to manage.

In the other hand if you want to be able to export and import your user information in different environments then you should use fields.


user.data service

This is schema of table users_data. User data service will stored data in this table. enter image description here And here are some data examples

enter image description here Data of user will save in field value. This field has type longblob. Imagine, Customer want to filter all user enable allow contact. So what you will do?

So I think, just use user.data service when you need store data for user, don't need filter, compare... data with other user.

  • 1
    I like your last sentence. The power of fields is that they can be searched and filtered, ect, but at the cost of more overhead (more tables, more join queries...) Not requiring that functionality is a perfect reason to use the data storage. Jul 17, 2018 at 18:26

The only limitation of the user.data service is how you can retrieve the data, since you can do it by:

  • $module, $name, and $uid
  • $module and $uid
  • $module and $name
  • $module only

For example, you can find all the values a module set for a specific user passing $module and $uid, or find all the values set by a module passing only $module.
The data stored is serialized, though. If you need to index values using something else than module name, user ID, or a name assigned to the data, you need to create your own database table.

The pro of using the user.data module is that modules don't need to create the database table to store the data, and that the stored data is automatically deleted when a module is uninstalled (and in this case, all the data stored for that module is deleted) or when a user account is deleted (and in this case, all the data stored from the user.data service for that account, from any module, is deleted). This means less code for modules.

Entity fields aren't used to store preference, or information a module gather about users, but rather properties of the entity.

I would use the user.data service, except when it makes more complicated retrieving/altering the stored data. If I were to write a module that saves the IPs from which users access a Drupal site (including the first and the last time an IP was used from a user) to then check which users connected contemporary from the same IP, I would not use the user.data service, but a custom database table where each row contains user ID and IP, which allows to aggregate data and still be able to handle the information separately.

As for the database table growing quite fast, I would not worry about that, if using the user.data service is not causing data duplication. Using the previous example of storing the IP from which the users connect to a Drupal site, if the module is using $user_data->set('mymodule', $uid, 'ips', $list_of_ips) to store the list of IPs used from a user and $user_data->set('mymodule', $uid, "ips:$current_ip", TRUE) to quickly find the list of users using a specific IP with $user_data->get('mymodule', NULL, "ips:$ip"), then that is something to worry (and a sign that a different approach is better).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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