What are backward, forward and full compatibility?

Compatibility modes define which schema versions can read data written by which other versions. Backward compatibility means a new schema can read data written by the previous schema. In practice, this means consumers using the new schema can read old data. It is achieved by adding optional fields with defaults or removing fields that consumers do not need. Forward compatibility means the previous schema can read data written by the new schema. In practice, this means old consumers can read new data. It is achieved by only adding optional fields and never removing required fields. Full compatibility means both directions work: new consumers can read old data and old consumers can read new data. It is the strictest and safest mode, and it is achieved by only adding or removing optional fields with defaults. In a schema registry, the compatibility policy determines whether a new schema version is allowed to register.

The mechanism matters because it determines the order in which you can deploy changes. If you use backward compatibility, you must deploy the new consumer before the new producer, because the new consumer can read old data but old consumers cannot read new data. If you use forward compatibility, you must deploy the new producer before the new consumer, because old consumers can read new data but new consumers cannot read old data. If you use full compatibility, order does not matter because both directions work. This is why full compatibility is the safest for shared topics: it removes the coordination requirement between producer and consumer teams. The trade-off is flexibility: full compatibility is the most restrictive, so some changes that would be allowed under backward or forward compatibility are rejected. For example, adding a required field is never compatible under any mode; it must have a default.

A common mistake is to confuse the direction of compatibility with the direction of data flow. Backward compatibility is about new consumers reading old data, not about producers. Another mistake is to assume that backward compatibility is always sufficient. If a producer deploys a new schema that is backward-compatible but not forward-compatible, old consumers will break until they are upgraded. This is why the deployment order matters and why many teams use full compatibility for topics with many consumers. A third mistake is to set compatibility to NONE and rely on manual review; this works until someone makes a mistake, and then consumers break in production. Version note: Confluent Schema Registry supports BACKWARD, FORWARD, FULL, and their transitive variants (BACKWARD_TRANSITIVE, FORWARD_TRANSITIVE, FULL_TRANSITIVE). The transitive variants check compatibility against all previous versions, not just the latest. This is important for topics where consumers may be many versions behind.