Apicurio Registry
Apicurio Registry is an Apache-2.0 registry that stores schemas and API definitions together — Avro, Protobuf, JSON Schema, OpenAPI, AsyncAPI, GraphQL, WSDL and XSD — behind a REST API, with a Confluent-compatible endpoint so existing Kafka clients work unchanged.
LicenseOpen source (permissive)· Apache-2.0
DeploymentSelf-hosted
PricingFree
Operational complexityLow
WorkloadStreaming
LanguageJava
Use it when
- Event schemas and API contracts should live in one versioned store: Avro, Protobuf, and JSON Schema beside OpenAPI, AsyncAPI, GraphQL, WSDL, and XSD.
- Confluent clients must keep working; the ccompat endpoints serve them unchanged, so migration needs no code changes.
- You would rather back a registry with PostgreSQL than with a Kafka topic, or skip the database and use Kafka storage instead; both are supported.
- Apache-2.0 licensing and owner-only authorization with OIDC roles fit your governance better than a commercial registry.
Think twice when
- All you store is Kafka topic schemas; Confluent's registry or Karapace covers that with a smaller conceptual surface.
- A managed service is required; none exists, and Red Hat's supported build is still something you run.
- Code generation from the registry is expected; schemas come out through the API and the ordinary toolchain compiles them.
How it runs
A Quarkus service with a choice of store: embedded H2 for development, PostgreSQL recommended for production, or Kafka for teams avoiding a database. Compatibility rules (seven levels, plus validity and integrity checks) gate registration; a Kubernetes Operator handles deployment.
Details
CompareHow Apicurio Registry answers the questions Schema Registries turns on.
Schema Registries
| How it works | |
| Schema formats | Nine artifact types, and the breadth is the reason to choose it, Avro, Protobuf and JSON Schema for events, beside OpenAPI, AsyncAPI, GraphQL, WSDL, XSD and Kafka Connect schemas, so event contracts and API contracts sit in one versioned store. Custom artifact types can be added at deployment time |
| Protocol | Its own Core Registry API at v3, with v2 kept for backward compatibility, plus Confluent Schema Registry compatibility endpoints at /apis/ccompat/v7 and v8 so Confluent clients work unchanged, though Schema Linking, Data Contracts and client-side encryption are outside what that compatibility covers |
| Compatibility rules | Seven levels on the COMPATIBILITY rule (NONE, BACKWARD, BACKWARD_TRANSITIVE, FORWARD, FORWARD_TRANSITIVE, FULL and FULL_TRANSITIVE) with two further rule types beside it: VALIDITY, which checks the content parses, and INTEGRITY, which checks that references resolve |
| Where enforced | At registration, server-side: a rule set globally or on a single artifact decides whether a new version is accepted, so the registry itself is the gate. The Maven plugin's test-update goal moves the same check earlier, failing a build before anything is registered |
| Running it | |
| What you run | A Quarkus service with a choice of store, embedded H2 for development only, PostgreSQL as the recommended production option, or Apache Kafka for teams who would rather not run a database. The PostgreSQL path is what lets it need no Kafka at all, unlike registries that keep their state in a topic |
| Connections | |
| Client libraries | Java serialisers and deserialisers for Avro, Protobuf and JSON Schema that fetch schemas at runtime, and Confluent's own client libraries work unchanged against the compatibility endpoint; a Python client SDK covers the registry API itself |
| Generated code | Not from the registry: its Maven plugin registers, downloads and tests artifacts, and downloading is how a schema reaches the ordinary Avro or Protobuf compiler. Apicurio Codegen, which generates code from API definitions, is a separate project rather than part of this one |
| Connectors | Kafka Connect is a first-class artifact type with converters to match, and the Confluent-compatible endpoint means anything already speaking that API connects without change; a Kubernetes Operator handles deployment |
| Access | |
| Access control | Three roles (admin, developer and read-only) mapped from OIDC through Keycloak or another provider, with owner-only authorisation available so that only an artifact's creator may change it, and an admin override for granting the admin role. Rules attach globally or per artifact, so who may evolve a schema and how are configured separately |
| Cost | |
| Billing unit | Nothing to pay: Apache-2.0 with no commercial edition from the project. Red Hat ships a supported build, so a subscription buys support and a distribution rather than a different product, and no managed service exists at all |
Alternatives to Apicurio Registry
