Schema evolution limits: rollback safety after a schema change in Pulsar

Direct answer

Pulsar does not provide a native, transactional way to "roll back" a topic’s schema to a previous version while guaranteeing that all existing data remains readable. The schema registry stores each version, but messages retain the schema version they were written with, so changing the registry version alone does not alter stored data. Whether a rollback is safe depends entirely on the compatibility mode in effect and on the nature of the schema change (additive vs. breaking).

Confirmed facts

• Schema compatibility is enforced at write time according to the namespace/topic strategy (BACKWARD, FORWARD, FULL, ALWAYS_COMPATIBLE, ALWAYS_INCOMPATIBLE). A new version is accepted only if it passes the check against the existing versions.
• If the strategy is BACKWARD or FULL, a schema that only adds optional fields (or provides defaults) can be read by consumers using the older schema; removing or renaming required fields breaks this guarantee.
• Changing the registry to an older version does not affect data already persisted in BookKeeper; consumers will still attempt to decode messages using the schema version embedded in each message.
• There is no feature that automatically reverts a topic to a prior schema version or that provides a versioned "rollback" store; the schema registry is append‑only.
• The ability to configure schema compatibility strategies has been present since early 2.x releases (e.g., 2.0.0) and has not changed fundamentally in later versions.

Likely explanation / practical guidance

To safely revert to an earlier schema without data loss, follow these steps:

1. Check the current compatibility strategy for the namespace/topic (e.g., pulsar-admin namespaces get-schema-compatibility-strategy). If it is not BACKWARD or FULL, a rollback may be unsafe.
2. Verify the schema difference between the current version and the target older version (pulsar-admin schemas get --version N). Ensure the change is additive only (new optional fields with defaults).
3. Deploy consumer updates first** (if needed) so they can handle both schema versions; consumers should be compatible with the older schema (FORWARD compatibility) if they will remain after the producer rollback.
4. Roll back the producer** to the older schema version. Because the strategy is BACKWARD/FULL and the change is additive, existing messages written with the newer schema remain readable by the older producer/consumer pair.
5. Monitor logs** for SchemaCompatibilityException or IncompatibleSchemaException around the rollback window to confirm no incompatible writes were accepted.

If an incompatible change (e.g., removal of a required field) was already written to the topic, the only safe path is to create a new topic with the old schema and replay/migrate the data, or treat the version as a breaking change and keep both schema versions in use.

Missing diagnostic detail

To confirm whether the recommended steps apply, we need to know the effective schema compatibility strategy for the affected namespace/topic. If you can provide that, we can verify whether a rollback is safe without additional data migration.