# Schema Registry (/connectors/kafka/how-to/schema-registry)



There are two separate questions, and both answers are yes.

**Do my serializers work?** Yes, unchanged. Avro, Protobuf and JSON Schema serializers put a magic
byte and a schema id in front of each value. The broker never looks inside a value, so the bytes a
producer writes are the bytes a consumer reads, and the consumer's deserializer resolves the id
against your registry exactly as before.

**Can the registry itself run on KubeMQ?** Yes. KubeMQ does not include a schema registry, but the
Confluent Schema Registry service stores its schemas in a Kafka topic (`_schemas`), and it can use
KubeMQ as that Kafka.

## Running the registry against KubeMQ [#running-the-registry-against-kubemq]

```properties title="schema-registry.properties"
listeners=http://0.0.0.0:8081
kafkastore.bootstrap.servers=PLAINTEXT://kubemq-next-kafka.kubemq.svc:9092
kafkastore.topic=_schemas

# The registry's default is 3. From next v1.2.0 KubeMQ accepts any value up to its node count;
# use 1 on a single node. Next v1.1.0 and earlier accepted only 1.
kafkastore.topic.replication.factor=3
```

`_schemas` is a compacted topic; compaction runs on the `next` storage engine the Kafka connector
always uses. Point the registry at any node — topic creation sent to a follower is forwarded to the
cluster leader.

## Moving an existing registry [#moving-an-existing-registry]

Your schema ids live in `_schemas`, and every record already written carries one. Moving the registry
means moving that topic with its data, so the ids keep resolving: when you migrate with `kmq migrate`,
check that `_schemas` is in the topic list `assess` reports before you run `replicate`. The
alternative is to keep the old registry running until every record written with its ids has aged
out. See [Migrate from Kafka](/connectors/kafka/how-to/migrate-from-kafka).

The [Fitness Matrix](/connectors/kafka/reference/fitness-matrix) carries the proof tier for both the
serializers and the registry service.