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 will set compatibility policies when you add a schema. Once a compatible policy is set, it cannot be changed. The default is BACKWARD.

You can configure compatibility using any of the following values.

BACKWARD: (Default) A new registered schema version (X) is compatible with the last registered schema version (X-1). Consumers using the new registered schema version (X) can deserialize and read data written by producers that used the last registered schema (X-1).
For example, given schemas X (newest), X-1, and X-2 (oldest), consumers using schema X can process data produced with schema X or X-1 but possibly not X-2.

Changes allowed: You can evolve schemas by deleting portions of the schema. A consumer created to process events without a field will ignore the field when processing events written with the old schema. You can add optional fields.

FORWARD: The latest registered schema version (X-1) is compatible with a new schema version (X). Consumers using the latest registered schema version (X-1) can deserialize and read data written by producers using the new schema version (X).
For example, given schemas X (newest), X-1, and X-2 (oldest), data produced with schema X can be read by consumers using schema X or X-1 but possibly not X-2.
Changes allowed: You can evolve schemas by adding fields. You can delete optional fields.

FULL: A new schema version provides both forward and backward compatibility. Old data can be read with the new schema. New data can be read with the last schema.
For example, given schemas X (newest), X-1, and X-2 (oldest), consumers using schema X can process data produced with schema X or X-1 but possibly not X-2. Data produced with schema X can be read by consumers using schema X or X-1 but possibly not X-2.
Changes allowed: You can add optional fields and delete optional fields.
NONE: No compatibility policy exists and there is no compatibility checking. All changes are accepted. To evolve a schema, you can do one of the following:
- Upgrade all producers and consumers to the new schema version.
- Create a new topic and migrate applications to use the new topic and new schema.

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