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: GET /schemas/types returns exactly ["AVRO", "JSON", "PROTOBUF"].

​

Where it runs

​

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. For what each mode permits, which side you upgrade first, and how to set the mode on a subject, see Schema evolution and compatibility.

​

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.

​

Next steps