# When to use Schema Registry Schema Registry is the source of truth for the structure of event data in a Kafka deployment, and production deployments require it. Without Schema Registry, producers and consumers operate on undocumented format assumptions that fail silently when fields change. Schema Registry catches incompatible changes at registration time, before they reach consumers. ## Common failure modes without schemas When producers and consumers share no schema contract, the failure modes are predictable. ### Field-rename outages A producer renames `userId` to `user_id`. Consumers parse messages by string key. Every downstream service that reads the field emits nulls or throws parse errors. No central system detected the change before deployment. ### Type-drift corruption A field that was an integer arrives as a string. JSON-only pipelines silently coerce or drop the value. The data warehouse loads bad data for hours before anyone notices. ### Compatibility surprises during upgrades A team adds a required field to an event. Older consumers that don’t know about the field fail to deserialize. The team that added the field had no way to discover the consumer contract. ### Recovery without a record When a schema mismatch happens, no history exists of the prior message format. Engineers reconstruct the old schema by reading source code across dozens of repositories. ## Cost comparison Adding Schema Registry to a new client is a one-time configuration change: set a serializer and point it at the registry URL. Adding Schema Registry to an existing client takes longer because it requires re-serializing data, updating the topic, and coordinating consumers. Recovering from a schema-mismatch incident in production is a multi-day, cross-team effort that can involve root-cause analysis, replaying data, manual data fixes, and a retrospective. ## When Schema Registry applies Schema Registry applies whenever events flow between systems that don’t share a single release cadence. Concrete cases include: - Multi-team Kafka deployments. - Data pipelines that cross a team or organization boundary. - Systems where consumers and producers ship on independent timelines. - Topics where schema changes happen over the lifetime of the system. In practice, that covers essentially every production Kafka deployment. ## Get started - Confluent Cloud: [Confluent Cloud Schema Registry Tutorial](/cloud/current/sr/schema_registry_ccloud_tutorial.html) - Confluent Platform: [On-Premises Schema Registry Tutorial](/platform/current/schema-registry/schema_registry_onprem_tutorial.html) - Course: [Schema Registry 101](https://developer.confluent.io/learn-kafka/schema-registry/) ## Tools for adopting Schema Registry Adopt Schema Registry at any stage of a project, including on data that already exists: - Sample client code: [confluentinc/examples](https://github.com/confluentinc/examples). - Compatibility checks in a build pipeline: [Schema Registry Maven Plugin](develop/maven-plugin.md#sr-maven-plugin). - A schema for an existing topic that has none: [Infer a schema from messages](/cloud/current/sr/schemas-manage.html#infer-a-schema-from-messages). - A schema for data already in flight, without re-serializing it: [schema GUID in record header](fundamentals/serdes-develop/index.md#messages-wire-format-schema-id-in-header).