Compatibility Types

In the Schema Registry, compatibility policies are created at the schema metadata level and define the evolution rules for each schema. If the Schema Repository determines a schema is not compatible, an error is returned.

Important: You set compatibility policies when you add a schema. Once a compatible policy is set, it should not be changed. The default is BACKWARD.

You can configure compatibility using any of the following values.

  • BACKWARD: (Default) A newly registered schema version must be compatible with the last registered version. This means that a consumer using the newly registered version of a schema is able to deserialize data written by producers that used the previous version.

    Changes allowed:

    • Deleting fields

    • Adding optional fields

  • BACKWARD_TRANSITIVE: A newly registered schema version must be compatible with all previous registered versions. This means that a consumer using the newly registered version of a schema is able to deserialize data written by producers that used any previous version.

    Changes allowed:

    • Deleting fields

    • Adding optional fields

  • FORWARD: The last registered schema version must be compatible with a newly registered version. This means that a consumer using the last registered version of a schema is able to deserialize data written by producers using the newly registered version of a schema.

    Changes allowed:

    • Adding fields

    • Deleting optional fields

  • FORWARD_TRANSITIVE: All previously registered schema versions must be compatible with a newly registered version. This means that a consumer using any previously registered version of a schema is able to deserialize data written by producers using the most newly registered version of a schema.

    Changes allowed:

    • Adding fields

    • Deleting optional fields

  • FULL: A newly registered schema must be both forward and backward compatible. This means that a consumer using the newly registered version of a schema is able to deserialize data written by producers that used the previous version, and a consumer using the last registered version of a schema is able to deserialize data written by producers using the newly registered version of a schema.

    Changes allowed:

    • Adding optional fields

    • Deleting optional fields

  • FULL_TRANSITIVE: A newly registered schema must be both forward transitive and backward transitive compatible. This means that a consumer using any version of a schema will be able to process data produced with any other version of the same schema.

    Changes allowed:

    • Adding optional fields

    • Deleting optional fields

  • NONE: No compatibility policy exists, and there is no compatibility checking.

    Changes allowed:

    • All changes are allowed

Important: If you set transitive configurations (FULL_TRANSITIVE, BACKWARD_TRANSITIVE, or FORWARD_TRANSITIVE), no error is produced. However, the compatibility check is only against the last schema, not all schemas.