# Use Schema Registry in Redpanda Console > For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [streaming-full.txt](https://docs.redpanda.com/streaming-full.txt) --- title: Use Schema Registry in Redpanda Console latest-operator-version: v26.1.4 # EOL = End-of-Life (support lifecycle status) page-is-nearing-eol: "false" page-is-past-eol: "true" page-eol-date: July 31, 2025 latest-console-tag: v3.7.3 latest-connect-version: 4.93.0 docname: ui/schema-reg page-component-name: streaming page-version: "24.2" page-component-version: "24.2" page-component-title: Streaming page-relative-src-path: ui/schema-reg.adoc page-edit-url: https://github.com/redpanda-data/docs/edit/v/24.2/modules/console/pages/ui/schema-reg.adoc description: Perform common Schema Registry management operations in the Redpanda Console. page-git-created-date: "2024-09-11" page-git-modified-date: "2024-09-11" support-status: past end-of-life --- In Redpanda Console, the **Schema Registry** menu lists registered and verified schemas, including their serialization format and versions. Select an individual schema to see which topics it applies to. > 📝 **NOTE** > > The Schema Registry is built into Redpanda, and you can use it with the Schema Registry API or with Redpanda Console. This section describes Schema Registry operations available in Redpanda Console. ## [](#prerequisites)Prerequisites You must add a valid `schemaRegistry` configuration in Redpanda Console. For help configuring Redpanda Console to connect to Schema Registry, see [Configure Message Deserialization in Redpanda Console](https://docs.redpanda.com/streaming/24.2/console/config/deserialization/). ## [](#create-or-edit-a-schema)Create or edit a schema A schema is registered in the registry with a _subject_, which is a name that is associated with the schema as it evolves. To register a schema, click **Create new schema**. 1. On the **Create schema** page, select the strategy type for how to derive the subject name. - **Topic** (default): The subject name is derived from the Redpanda topic name. See [Topic strategy use case](#topic-strategy-use-case). - **Record**: The subject name is derived from the Kafka record name. See [Record strategy use case](#record-strategy-use-case). - **TopicRecord**: The subject name is derived from both topic name and record name, allowing for finer-grained schema organization. See [TopicRecord strategy use case](#topicrecord-strategy-use-case). - **Custom**: The subject name is user-defined. 2. Select the serialization format with the schema definition. 3. To build more complex schema definitions, add a reference to other schemas. For example, the two `import` statements are references to the `PhoneNumber` and `Address` schemas: ```json { syntax = "proto3"; import "PhoneNumber.proto"; import "Address.proto"; message Person { string name = 1; string email = 2; PhoneNumber phone = 3; repeated Address address = 4; } ``` 4. After registering a schema, you can add a new version to it, change its compatibility, or delete it. ### [](#topic-strategy-use-case)Topic strategy use case The Topic strategy is suitable when you want to group schemas by the topics to which they are associated. Suppose you’re tracking product order information in a topic named `Transactions`. When a producer sends records to the `OrderInfo` topic, you want the record names to look something like: - `Transactions - Record1` - `Transactions - Record2` Where `Record1` and `Record2` are unique identifiers. This is usually defined in your producer settings. Create your schema with the Topic strategy, and the subject name is always `Transactions`, with all customer transactions under the same topic. ### [](#record-strategy-use-case)Record strategy use case The Record strategy is most useful when you have multiple schemas within a topic and need more granular categorization that’s influenced by the record name. Suppose there’s an `Events` topic with event types A and B. You may want each of those event types to have their own subject, their own schemas, and their own fully-qualified record names (for example, `com.example.EventTypeA`). If each event type has its own schema with the Record strategy, then when producers send these event types to the `Events` topic, their subjects are those record names: - `com.example.EventTypeA` - `com.example.EventTypeB` The record names in the Events topic look like this: - `Events-com.example.EventTypeA-Record1` - `Events-com.example.EventTypeB-Record1` - `Events-com.example.EventTypeA-Record2` - `Events-com.example.EventTypeB-Record2` ### [](#topicrecord-strategy-use-case)TopicRecord strategy use case The TopicRecord strategy is suitable when you want to organize schemas based on both topics and logical record types. Suppose there’s a microservices architecture where different services produce to the same topic: `SharedEvents`. Each microservice has a schema of its own for the shared events, but each schema uses the TopicRecord strategy. This results in the following subject names: - `SharedEvents-com.example.MicroserviceAEvent` - `SharedEvents-com.example.MicroserviceBEvent` The record names look like this: - `SharedEvents-com.example.MicroserviceAEvent-Record1` - `SharedEvents-com.example.MicroserviceBEvent-Record1` - `SharedEvents-com.example.MicroserviceAEvent-Record2` - `SharedEvents-com.example.MicroserviceBEvent-Record2` This allows for multiple schemas to govern the same shared events for different microservices, allowing granular organization. ## [](#configure-schema-compatibility)Configure schema compatibility Applications are often modeled around a specific business object structure. As applications change and the shape of their data changes, producer schemas and consumer schemas may no longer be compatible. You can decide how a consumer handles data from a producer that uses an older or newer schema, and reduce the chance of consumers hitting deserialization errors. You can configure different types of schema compatibility, which are applied to a subject when a new schema is registered. The Schema Registry supports the following compatibility types: - `BACKWARD` (**default**) - Consumers using the new schema (for example, version 10) can read data from producers using the previous schema (for example, version 9). - `BACKWARD_TRANSITIVE` - Consumers using the new schema (for example, version 10) can read data from producers using all previous schemas (for example, versions 1-9). - `FORWARD` - Consumers using the previous schema (for example, version 9) can read data from producers using the new schema (for example, version 10). - `FORWARD_TRANSITIVE` - Consumers using any previous schema (for example, versions 1-9) can read data from producers using the new schema (for example, version 10). - `FULL` - A new schema and the previous schema (for example, versions 10 and 9) are both backward and forward compatible with each other. - `FULL_TRANSITIVE` - Each schema is both backward and forward compatible with all registered schemas. - `NONE` - No schema compatibility checks are done. ### [](#compatibility-uses-and-constraints)Compatibility uses and constraints - A consumer that wants to read a topic from the beginning (for example, an AI learning process) benefits from backward compatibility. It can process the whole topic using the latest schema. This allows producers to remove fields and add attributes. - A real-time consumer that doesn’t care about historical events but wants to keep up with the latest data (for example, a typical streaming application) benefits from forward compatibility. Even if producers change the schema, the consumer can carry on. - Full compatibility can process historical data and future data. This is the safest option, but it limits the changes that can be done. This only allows for the addition and removal of optional fields. If you make changes that are not inherently backward-compatible, you may need to change compatibility settings or plan a transitional period, updating producers and consumers to use the new schema while the old one is still accepted. | Schema format | Backward-compatible tasks | Not backward-compatible tasks | | --- | --- | --- | | Avro | Add fields with default valuesMake fields nullable | Remove fieldsChange data types of fieldsChange enum valuesChange field constraintsChange record of field names | | Protobuf | Add fieldsRemove fields | Remove required fieldsChange data types of fields | | JSON | Add optional propertiesRelax constraints, for example:Decrease a minimum value or increase a maximum valueDecrease minItems, minLength, or minProperties; increase maxItems, maxLength, maxPropertiesAdd more property types (for example, "type": "integer" to "type": ["integer", "string"])Add more enum valuesReduce multipleOf by an integral factorRelaxing additional properties if additionalProperties was not previously specified as falseRemoving a uniqueItems property that was false | Remove propertiesAdd required propertiesChange property names and typesTighten or add constraints | ## [](#delete-a-schema)Delete a schema Select a schema to soft-delete a version of it or all schemas of its subject. Schemas cannot be deleted if any other schemas reference it. A soft-deleted schema can be recovered, but a permanently-deleted schema cannot be recovered. Redpanda does not recommend permanently deleting schemas in a production environment. ## [](#suggested-reading)Suggested reading - [Configure Message Deserialization in Redpanda Console](https://docs.redpanda.com/streaming/24.2/console/config/deserialization/) - [Redpanda Schema Registry](https://docs.redpanda.com/streaming/24.2/manage/schema-reg/schema-reg-overview/)