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

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

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.

The Fitness Matrix carries the proof tier for both the serializers and the registry service.