Schema Registry

Schema Registry attaches a versioned data contract to a managed topic. It helps producers and consumers agree on field names and types before incompatible data reaches the stream.

Supported schema files

Format	File extension	Common use
Avro	`.avsc`	Compact event records with broad streaming support
Protobuf	`.proto`	Strongly typed messages shared across application languages
JSON Schema	`.json`	Human-readable JSON validation

Only broker-managed topics appear in Schema Registry.

Register the first schema

Open Schema Registry

Select the managed topic from Eligible topics.

Review the policy

Choose the compatibility mode, maximum version count, and maximum file size.

Choose a schema file

Select a supported .avsc, .proto, or .json file from your computer.

Upload the schema

Select Upload to Pulsar. The schema becomes the active version when it passes validation and compatibility checks.

Compatibility modes

Mode	What it protects
`Backward`	New consumers can read records written with the previous schema
`Forward`	Existing consumers can read records written with the new schema
`Full`	Both backward and forward compatibility with the previous schema
`Backward transitive`	Backward compatibility with every retained version
`Forward transitive`	Forward compatibility with every retained version
`Full transitive`	Both directions against every retained version
`Always compatible`	Accepts any valid new definition
`Always incompatible`	Rejects every new version

Tip

Use Full as a balanced starting point. Use a transitive mode when long-lived applications may still depend on much older schema versions.

Version and size limits

Maximum versions accepts values from 1 to 1000.
Maximum schema size (KiB) accepts values from 1 to 512.

Keep enough versions to cover your deployment and rollback window. A smaller size limit makes accidental oversized definitions easier to catch.

Restore an earlier definition

Schema Registry keeps a recorded version history. To restore an earlier definition:

Find the required version in Recorded version history.
Select Restore as new version.
Confirm that the restored definition becomes the latest active version.

Restoring does not erase newer history. It creates a new version from the selected older definition, preserving a complete audit trail.

Before changing a production schema

Confirm the active compatibility mode.
Test the new definition with current producers and consumers.
Roll out tolerant consumers before producers when introducing new fields.
Avoid renaming or changing the type of an existing field without a migration plan.
Check Audit Logs after the change.