+
+
+
+|
+
+Compatibility check strategy
+
+ |
+
+
+
+Definition
+
+ |
+
+
+
+Changes allowed
+
+ |
+
+
+
+Check against which schema
+
+ |
+
+
+
+Upgrade first
+
+ |
+
+
+
+
+
+|
+
+`ALWAYS_COMPATIBLE`
+
+ |
+
+
+
+Disable schema compatibility check.
+
+ |
+
+
+
+All changes are allowed
+
+ |
+
+
+
+All previous versions
+
+ |
+
+
+
+Any order
+
+ |
+
+
+
+
+
+|
+
+`ALWAYS_INCOMPATIBLE`
+
+ |
+
+
+
+Disable schema evolution.
+
+ |
+
+
+
+All changes are disabled
+
+ |
+
+
+
+None
+
+ |
+
+
+
+None
+
+ |
+
+
+
+
+
+|
+
+`BACKWARD`
+
+ |
+
+
+
+Consumers using the schema V3 can process data written by producers using the schema V3 or V2.
+
+ |
+
+
+
+* Add optional fields
+
+* Delete fields
+
+ |
+
+
+
+Latest version
+
+ |
+
+
+
+Consumers
+
+ |
+
+
+
+
+
+|
+
+`BACKWARD_TRANSITIVE`
+
+ |
+
+
+
+Consumers using the schema V3 can process data written by producers using the schema V3, V2 or V1.
+
+ |
+
+
+
+* Add optional fields
+
+* Delete fields
+
+ |
+
+
+
+All previous versions
+
+ |
+
+
+
+Consumers
+
+ |
+
+
+
+
+
+|
+
+`FORWARD`
+
+ |
+
+
+
+Consumers using the schema V3 or V2 can process data written by producers using the schema V3.
+
+ |
+
+
+
+* Add fields
+
+* Delete optional fields
+
+ |
+
+
+
+Latest version
+
+ |
+
+
+
+Producers
+
+ |
+
+
+
+
+
+|
+
+`FORWARD_TRANSITIVE`
+
+ |
+
+
+
+Consumers using the schema V3, V2 or V1 can process data written by producers using the schema V3.
+
+ |
+
+
+
+* Add fields
+
+* Delete optional fields
+
+ |
+
+
+
+All previous versions
+
+ |
+
+
+
+Producers
+
+ |
+
+
+
+
+
+|
+
+`FULL`
+
+ |
+
+
+
+Backward and forward compatible between the schema V3 and V2.
+
+ |
+
+
+
+* Modify optional fields
+
+ |
+
+
+
+Latest version
+
+ |
+
+
+
+Any order
+
+ |
+
+
+
+
+
+|
+
+`FULL_TRANSITIVE`
+
+ |
+
+
+
+Backward and forward compatible among the schema V3, V2, and V1.
+
+ |
+
+
+
+* Modify optional fields
+
+ |
+
+
+
+All previous versions
+
+ |
+
+
+
+Any order
+
+ |
+
+
+
+
+
+### ALWAYS_COMPATIBLE and ALWAYS_INCOMPATIBLE
+
+
+
+
+
+|
+
+Compatibility check strategy
+
+ |
+
+
+
+Definition
+
+ |
+
+
+
+Description
+
+ |
+
+
+
+Note
+
+ |
+
+
+
+
+
+|
+
+`FULL`
+
+ |
+
+
+
+Schemas are both backward and forward compatible, which means:
+
+Consumers using the last schema can process data written by producers using the new schema.
+
+AND
+
+Consumers using the new schema can process data written by producers using the last schema.
+
+ |
+
+
+
+Consumers using the schema V3 can process data written by producers using the schema V3 or V2.
+
+AND
+
+Consumers using the schema V3 or V2 can process data written by producers using the schema V3.
+
+ |
+
+
+
+* For Avro and JSON, the default schema compatibility check strategy is `FULL`.
+
+* For all schema types except Avro and JSON, the default schema compatibility check strategy is `ALWAYS_INCOMPATIBLE`.
+
+ |
+
+
+
+
+
+|
+
+`FULL_TRANSITIVE`
+
+ |
+
+
+
+The new schema is backward and forward compatible with all previously registered schemas.
+
+ |
+
+
+
+Consumers using the schema V3 can process data written by producers using the schema V3, V2 or V1.
+
+AND
+
+Consumers using the schema V3, V2 or V1 can process data written by producers using the schema V3.
+
+ |
+
+
+
+None
+
+ |
+
+
+
+
+
+#### Example
+
+In some data formats, for example, Avro, you can define fields with default values. Consequently, adding or removing a field with a default value is a fully compatible change.
+
+## Schema verification
+
+When a producer or a consumer tries to connect to a topic, a broker performs some checks to verify a schema.
+
+### Producer
+
+When a producer tries to connect to a topic (suppose ignore the schema auto creation), a broker does the following checks:
+
+* Check if the schema carried by the producer exists in the schema registry or not.
+
+ * If the schema is already registered, then the producer is connected to a broker and produce messages with that schema.
+
+ * If the schema is not registered, then Pulsar verifies if the schema is allowed to be registered based on the configured compatibility check strategy.
+
+### Consumer
+When a consumer tries to connect to a topic, a broker checks if a carried schema is compatible with a registered schema based on the configured schema compatibility check strategy.
+
+
+
+
+
+|
+
+Compatibility check strategy
+
+ |
+
+
+
+Check logic
+
+ |
+
+
+
+
+
+|
+
+`ALWAYS_COMPATIBLE`
+
+ |
+
+
+
+All pass
+
+ |
+
+
+
+
+
+|
+
+`ALWAYS_INCOMPATIBLE`
+
+ |
+
+
+
+No pass
+
+ |
+
+
+
+
+
+|
+
+`BACKWARD`
+
+ |
+
+
+
+Can read the last schema
+
+ |
+
+
+
+
+
+|
+
+`BACKWARD_TRANSITIVE`
+
+ |
+
+
+
+Can read all schemas
+
+ |
+
+
+
+
+
+|
+
+`FORWARD`
+
+ |
+
+
+
+Can read the last schema
+
+ |
+
+
+
+
+
+|
+
+`FORWARD_TRANSITIVE`
+
+ |
+
+
+
+Can read the last schema
+
+ |
+
+
+
+
+
+|
+
+`FULL`
+
+ |
+
+
+
+Can read the last schema
+
+ |
+
+
+
+
+
+|
+
+`FULL_TRANSITIVE`
+
+ |
+
+
+
+Can read all schemas
+
+ |
+
+
+
+
+
+## Order of upgrading clients
+
+The order of upgrading client applications is determined by the compatibility check strategy.
+
+For example, the producers using schemas to write data to Pulsar and the consumers using schemas to read data from Pulsar.
+
+
+
+
+
+|
+
+Compatibility check strategy
+
+ |
+
+
+
+Upgrade first
+
+ |
+
+
+
+Description
+
+ |
+
+
+
+
+
+|
+
+`ALWAYS_COMPATIBLE`
+
+ |
+
+
+
+Any order
+
+ |
+
+
+
+The compatibility check is disabled.
+
+Consequently, you can upgrade the producers and consumers in **any order**.
+
+ |
+
+
+
+
+
+|
+
+`ALWAYS_INCOMPATIBLE`
+
+ |
+
+
+
+None
+
+ |
+
+
+
+The schema evolution is disabled.
+
+ |
+
+
+
+
+
+|
+
+* `BACKWARD`
+
+* `BACKWARD_TRANSITIVE`
+
+ |
+
+
+
+Consumers
+
+ |
+
+
+
+There is no guarantee that consumers using the old schema can read data produced using the new schema.
+
+Consequently, **upgrade all consumers first**, and then start producing new data.
+
+ |
+
+
+
+
+
+|
+
+* `FORWARD`
+
+* `FORWARD_TRANSITIVE`
+
+ |
+
+
+
+Producers
+
+ |
+
+
+
+There is no guarantee that consumers using the new schema can read data produced using the old schema.
+
+Consequently, **upgrade all producers first** to use the new schema and ensure that the data already produced using the old schemas are not available to consumers, and then upgrade the consumers.
+
+ |
+
+
+
+
+
+|
+
+* `FULL`
+
+* `FULL_TRANSITIVE`
+
+ |
+
+
+
+Any order
+
+ |
+
+
+
+There is no guarantee that consumers using the old schema can read data produced using the new schema and consumers using the new schema can read data produced using the old schema.
+
+Consequently, you can upgrade the producers and consumers in **any order**.
+
+ |
+
+
+
+
+
+
+
+
diff --git a/site2/website/versioned_docs/version-2.5.2/schema-get-started.md b/site2/website/versioned_docs/version-2.5.2/schema-get-started.md
new file mode 100644
index 0000000000000..e00cfbac5ee58
--- /dev/null
+++ b/site2/website/versioned_docs/version-2.5.2/schema-get-started.md
@@ -0,0 +1,91 @@
+---
+id: version-2.5.2-schema-get-started
+title: Get started
+sidebar_label: Get started
+original_id: schema-get-started
+---
+
+This chapter introduces Pulsar schemas and explains why they are important.
+
+## Schema Registry
+
+Type safety is extremely important in any application built around a message bus like Pulsar.
+
+Producers and consumers need some kind of mechanism for coordinating types at the topic level to avoid various potential problems arise. For example, serialization and deserialization issues.
+
+Applications typically adopt one of the following approaches to guarantee type safety in messaging. Both approaches are available in Pulsar, and you're free to adopt one or the other or to mix and match on a per-topic basis.
+
+### Client-side approach
+
+Producers and consumers are responsible for not only serializing and deserializing messages (which consist of raw bytes) but also "knowing" which types are being transmitted via which topics.
+
+If a producer is sending temperature sensor data on the topic `topic-1`, consumers of that topic will run into trouble if they attempt to parse that data as moisture sensor readings.
+
+Producers and consumers can send and receive messages consisting of raw byte arrays and leave all type safety enforcement to the application on an "out-of-band" basis.
+
+### Server-side approach
+
+Producers and consumers inform the system which data types can be transmitted via the topic.
+
+With this approach, the messaging system enforces type safety and ensures that producers and consumers remain synced.
+
+Pulsar has a built-in **schema registry** that enables clients to upload data schemas on a per-topic basis. Those schemas dictate which data types are recognized as valid for that topic.
+
+## Why use schema
+
+When a schema is enabled, Pulsar does parse data, it takes bytes as inputs and sends bytes as outputs. While data has meaning beyond bytes, you need to parse data and might encounter parse exceptions which mainly occur in the following situations:
+
+* The field does not exist
+
+* The field type has changed (for example, `string` is changed to `int`)
+
+There are a few methods to prevent and overcome these exceptions, for example, you can catch exceptions when parsing errors, which makes code hard to maintain; or you can adopt a schema management system to perform schema evolution, not to break downstream applications, and enforces type safety to max extend in the language you are using, the solution is Pulsar Schema.
+
+Pulsar schema enables you to use language-specific types of data when constructing and handling messages from simple types like `string` to more complex application-specific types.
+
+**Example**
+
+You can use the _User_ class to define the messages sent to Pulsar topics.
+
+```
+public class User {
+ String name;
+ int age;
+}
+```
+
+When constructing a producer with the _User_ class, you can specify a schema or not as below.
+
+### Without schema
+
+If you construct a producer without specifying a schema, then the producer can only produce messages of type `byte[]`. If you have a POJO class, you need to serialize the POJO into bytes before sending messages.
+
+**Example**
+
+```
+Producer