> ## Documentation Index
> Fetch the complete documentation index at: https://docs.streamnative.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Kafka Schema Registry

The Kafka Schema Registry on StreamNative Cloud stores and manages the schemas your producers and
consumers use. Producers register a schema, consumers retrieve it, and the registry keeps every
version and enforces a compatibility policy between them. When a producer tries to register a schema
version that would break existing consumers, the registry rejects it—so schema changes fail at
registration time rather than in production.

It's compatible with the Confluent Schema Registry API, which means the standard Confluent
serializers, deserializers, and REST clients work against it unchanged.

## What it is

A schema registry is two pieces working together:

* **A REST service** that stores schemas, assigns each one an ID and a version under a named
  subject, and runs the compatibility checks.
* **Serializers and deserializers** inside your Kafka clients. On the way out, the serializer
  registers or looks up the schema and prefixes each record with its schema ID. On the way in, the
  deserializer reads that ID, fetches the matching schema, and decodes the payload.

Because the record carries only a 4-byte schema ID instead of the full schema, schematized data is
smaller on the wire than self-describing formats—and every consumer resolves the exact schema the
producer used.

## Supported formats

The registry supports three schema formats:

| Format      | Serializer                  |
| ----------- | --------------------------- |
| Avro        | `KafkaAvroSerializer`       |
| JSON Schema | `KafkaJsonSchemaSerializer` |
| Protobuf    | `KafkaProtobufSerializer`   |

`GET /schemas/types` returns exactly `["AVRO", "JSON", "PROTOBUF"]`.

## Where it runs

| Cluster type       | Availability                                                                                                                                                                                                               |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Kafka cluster**  | Always available. The registry is served at the cluster's HTTP service URL.                                                                                                                                                |
| **Pulsar cluster** | Available when the Kafka protocol is enabled. The registry is served at the cluster's HTTP service URL with `/kafka` appended. See [Kafka Schema Registry on Pulsar clusters](/cloud/governance/sr/kafka-schema-registry). |

<Note title="Pulsar clusters run two registries">
  A Pulsar cluster also has the [Pulsar Schema Registry](/cloud/governance/sr/pulsar/overview) built
  into its brokers. The two are separate systems and are not interoperable. See
  [Data governance overview](/cloud/governance/governance-overview).
</Note>

## Configurable compatibility modes

Each subject has a compatibility mode that determines how the registry compares a new schema against
the versions already registered. A schema gets a unique ID and version 1 when it's first registered;
each subsequent version that passes the check gets a new ID and an incremented version number.

The default mode is **`BACKWARD`**.

| Mode                  | AVRO | JSON | Protobuf |
| --------------------- | ---- | ---- | -------- |
| `NONE`                | Yes  | Yes  | Yes      |
| `BACKWARD`            | Yes  | Yes  | Yes      |
| `BACKWARD_TRANSITIVE` | Yes  | Yes  | Yes      |
| `FORWARD`             | Yes  | Yes  | N/A      |
| `FORWARD_TRANSITIVE`  | Yes  | Yes  | N/A      |
| `FULL`                | Yes  | Yes  | N/A      |
| `FULL_TRANSITIVE`     | Yes  | Yes  | N/A      |

For what each mode permits, which side you upgrade first, and how to set the mode on a subject, see
[Schema evolution and compatibility](/kafka/governance/sr/fundamentals/schema-evolution).

## REST API

The registry exposes a subset of the Confluent Schema Registry REST API. For the full list of
supported endpoints and their query parameters, the endpoints that aren't implemented, and the
behavior differences you need to know about, see
[Confluent API compatibility](/kafka/governance/sr/reference/confluent-compatibility).

## Next steps

<CardGroup cols={2}>
  <Card title="Connect" icon="plug" href="/kafka/governance/sr/connect">
    Find the endpoint and configure client authentication.
  </Card>

  <Card title="Confluent compatibility" icon="list-check" href="/kafka/governance/sr/reference/confluent-compatibility">
    What's supported, what isn't, and where behavior differs.
  </Card>

  <Card title="Schema ID validation" icon="shield-check" href="/kafka/governance/sr/manage/schema-id-validation">
    Reject records that don't carry a registered schema ID.
  </Card>

  <Card title="Replicate schemas" icon="copy" href="/cookbook/kafka-schema-registry-geo-replication">
    Set up active-standby replication with Universal Linking.
  </Card>
</CardGroup>