---
title: "Kafka schema compatibility: BACKWARD vs FORWARD vs FULL"
description: "Confluent Schema Registry rejects a forward-only change under BACKWARD and accepts it under FORWARD; FULL needs both. The Kafka subject orders-value reaches v3."
url: https://monedula.dev/kafka-simulator/scenarios/compatibility-modes/
---

# Kafka schema compatibility: BACKWARD vs FORWARD vs FULL

Scenario 10.4.2 · Compatibility modes (backward/forward/full). Schema registry · Advanced · about 4 min · Apache Kafka 4.3 · Confluent Platform feature.

The mode decides what a new version may change. A forward-only change is rejected under backward, accepted under forward; full demands both directions.

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=10.4.2

## What you start with

A subject's compatibility mode decides which schema changes Schema Registry will accept. The same forward-only change is rejected under BACKWARD compatibility but accepted under FORWARD, while FULL requires the change to be safe in both directions at once.

## Step by step

1. **orders-value · backward** (t+0.000s): The subject orders-value starts at v1 under backward compatibility - Confluent's default. Backward means a consumer using the NEW schema can still read data written with the OLD one (so you may drop fields or add optional ones). [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.2&t=0)
2. **forward-only change rejected** (t+1.000s): We try to register a change that is forward-compatible but NOT backward-compatible - e.g. adding a required field. Under backward the registry refuses it: the version history does not advance and a schema_rejected event is emitted. Same change, wrong mode. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.2&t=1)
3. **mode → forward** (t+2.000s): Switch the subject's compatibility to forward. Forward means a consumer on the OLD schema can read data written with the NEW one (so you may add fields). The mode governs the NEXT registration. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.2&t=2)
4. **same change accepted · v2** (t+3.000s): Re-registering the very same forward-compatible change now succeeds - the subject advances to v2. The change never changed; only the mode did. That is the whole point of compatibility modes. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.2&t=3)
5. **mode → full** (t+4.000s): Tighten the subject to full. Full demands BOTH directions: a change must be backward- AND forward-compatible to be accepted. It is the strictest of the three teaching modes. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.2&t=4)
6. **backward-only change rejected** (t+5.000s): A change that is only backward-compatible is now rejected - full needs forward compatibility too. The subject stays at v2. Full is the intersection of backward and forward. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.2&t=5)
7. **fully-compatible change · v3** (t+6.000s): A change that is both backward- and forward-compatible passes even under full, advancing the subject to v3. Mode in hand: backward and forward each allow one direction; full requires both; none would allow anything. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.2&t=6)

## The takeaway

Pick the compatibility mode from your rollout order: BACKWARD when consumers upgrade first, FORWARD when producers upgrade first, and FULL when either side may upgrade in any order.

## Further reading

- [Confluent documentation](https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html)