How the handle an override of the schema of a field type To add other data to a state field, I overrode 2 functions of the StateItem class (from the state_item module)
    public static function schema(FieldStorageDefinitionInterface $field_definition) {
        $schema=StateItem::schema($field_definition);
        $schema['columns']['json']=[
            'type' =&gt; 'json',
            'pgsql_type' =&gt; 'json',
            'mysql_type' =&gt; 'json',
            'not null' =&gt; FALSE,
            'description' =&gt; &quot;Store data about states in json format&quot;,
        ];
        return $schema;
     }
    public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition) {
        $properties=parent::propertyDefinitions($field_definition);
        $properties['json']=DataDefinition::create('string')
        -&gt;setLabel(t('Data'));
        return $properties;
    }

As I have already several fields of this type in my website, I got the following errors in the Status report page:
Entity/field definitions  Mismatched entity and/or field definitions
                          The following changes were detected in the entity type and field definitions.

...followed by the fields that must be updated.
Knowing the fact that I am the only user of this custom field, what is the best approach to handle this kind of change?
Here is the solution
As explained by @sanzante, I created an UpdateN function which is updating all the fields of the state type by adding an appropriate column to the table of each field:
function mymodule_update_8001() {
  $spec = [
    'type' =&gt; 'json',
    'pgsql_type' =&gt; 'json',
    'mysql_type' =&gt; 'json',
    'not null' =&gt; FALSE,
    'description' =&gt; &quot;Store data about states in json format&quot;,
  ];
  $schema = Database::getConnection()-&gt;schema();
  $state_fields = \Drupal::service('entity_field.manager')
    -&gt;getFieldMapByFieldType('state');
  foreach ($state_fields as $entity_type_id =&gt; $fields) {
    foreach (array_keys($fields) as $field_name) {
      $table = $entity_type_id . '__' . $field_name;
      $table_rev = $entity_type_id.'_revision' . '__' . $field_name;
      $new_field_name = $field_name . '_json';
      $schema-&gt;addField($table, $new_field_name, $spec);
      $schema-&gt;addField($table_rev, $new_field_name, $spec);
    }
  }

}

The key points are :
1-how the table names are constructed. (see $table and $table_rev in the code)
2-how the new field names are constructed. (see $new_field_name in the code an the fact that you must use the same column name as defined in $schema['columns']['json'])
3-You must use the same spec as the ones defined in function schema
After the updated ran, I still got the Mismatched entity and/or field definitions error message.
I could solve this by running drush entup (the module devel_entity_updates must be installed)
You have to write an update function that changes those fields live in your database so they match the new definition.
Time ago, this was done using the drush entity-updates command. However, this was dangerous in some circumstances. You can check the Support for automatic entity updates has been removed change record to get more information on this.
In this change record you can see:

Starting with 8.7.0, Drupal core no longer provides support for
automatic entity updates. Whenever an entity type or field storage
definition needs to be created, changed or deleted, it has to be done
with an explicit update function as provided by the Update API, and
using the API provided by the entity definition update manager.

Therefore, you need an update function. Probably, you should read the &quot;Updating Database Schema and/or Data in Drupal 8&quot; page, specially the &quot;Adding a new column&quot; section:

Here's an example of what to put into your hook_update_N() function to
add a new column to an existing database table:
  $spec = [
    'type' =&gt; 'varchar',
    'description' =&gt; &quot;New Col&quot;,
    'length' =&gt; 20,
    'not null' =&gt; FALSE,
  ]; 
 $schema = Database::getConnection()-&gt;schema();
 $schema-&gt;addField('mytable1', 'newcol', $spec);


Devel Entity Updates module
As pointed out by @Ales, you may try the Devel Entity Updates module:

This command should be able to fully replace the legacy drush entup or
drush entity-updates commands.

However, this module is not meant to be used in production environments, see the following disclaimer from the module:

The goal of this module is to have a quick way to apply schema updates
while developing new entity types and ending up incrementally
adding/removing/changing entity type/field definitions.
When these changes are part of an official release (and not in the
scope of a code development session), they should absolutely rely on
DB update functions, as explained in the CR above, because that's the
only way the entity schema update process can be predictable and
reliable.

So, this approach is ok for you if don't have a production environment yet. Of course, you can ignore the warning and install the module on prod, but keep in mind that you may lose data because the operation is not safe.
You can try it on a test environment, and if you finally take the risk and use in prod make sure you have a recent backup at hand.
Why you need this
The problem you have a difference between the table data definition in code and the actual data tables in your database. Why does this happen? There are different circumstances that can lead to this. In your case, the State module has some data definitions that are applied when the module is installed. At this point, code data definition and actual data tables are matching. However, if you make any changes on the code that defines the data tables the problem arises: you have one definition on code and different actual data tables in the database.
So what you need to do is modify the tables to match the data definition. That's what my answer tries to explain. The two methods are writing an update function (so you control with that function how to modify the actual tables) or trust an automatic method (the entity update command). The command is easy but it has no brain so it just modifies the tables without thinking on possible issues. That's why you may have problems (data loss, mainly) using that command.