I’ve got several customer questions around our Kafka Schema Registry Apicurio and its features. Here are my results:

Red Hat Build of Apicurio Schema Registry

Comparison of Apicurio over Confluent

Red Hat Build of Apicurio

The Red Hat Build of Apicurio Schema Registry is Red Hat’s enterprise-supported offering of the open-source Apicurio Registry. It is designed for organizations that want the flexibility of open-source technology backed by the reliability and support of a major enterprise software vendor.

Advantages

  • Enterprise-Grade Open Source: You get the best of both worlds: the innovation and flexibility of a vibrant open-source community, combined with the security, stability, and expert support that comes with a Red Hat subscription. This is a significant advantage for organizations that have a mandate for open-source solutions but require enterprise-level assurances.
  • Deep Integration with the Red Hat Ecosystem: For organizations already invested in Red Hat technologies, the Apicurio Schema Registry offers seamless integration with Red Hat OpenShift (e.g. through the Apicurio operator), Red Hat Streams for Apache Kafka, and other parts of the Red Hat portfolio. This provides a unified experience for development, deployment, and management.
  • Broader Artifact Support: A key differentiator is its ability to store and manage a wider variety of artifacts beyond what is typically used with Kafka. This includes OpenAPI and AsyncAPI specifications, making it a central registry for both your event-driven and traditional API ecosystems. This broader scope can simplify your architecture and reduce the need for multiple registry solutions.
  • No Vendor Lock-In and Lower Total Cost of Ownership (TCO): Being fundamentally open-source, it prevents vendor lock-in. You can benefit from the enterprise features and support while retaining the freedom to use the community version. The subscription model can also lead to a lower TCO compared to the licensing costs of Confluent’s more advanced features.
  • Confluent API Compatibility: It provides a compatibility layer for the Confluent Schema Registry API. This is a major benefit for organizations looking to migrate from Confluent, as it allows for a “drop-in replacement” without needing to rewrite your Kafka client applications.

Disadvantages

  • Perceived Complexity Outside the Red Hat Ecosystem: For organizations that are not using Red Hat OpenShift or other Red Hat products, setting up and managing the Apicurio Schema Registry might be perceived as more complex than opting for Confluent’s more integrated platform.
  • Community vs. Enterprise Feature Lag: While the open-source project is innovative, there can sometimes be a lag between features appearing in the community version and them being fully supported in the official Red Hat build.

Confluent Schema Registry

Confluent Schema Registry is a mature, battle-tested component of the Confluent Platform, designed to provide a central source of truth for schemas in a Kafka-centric architecture.

Advantages

  • Tightest Integration with Apache Kafka: As a core part of the Confluent Platform, it offers the most seamless and deeply integrated experience for Kafka users. Features like the Confluent Control Center provide a unified UI for managing your entire Kafka ecosystem, including the schema registry.
  • Proven at Scale and Enterprise-Ready: It is used in production by a large number of enterprises for mission-critical applications, giving it a strong reputation for stability and performance at scale.
  • Managed Cloud Offering: Confluent Cloud provides a fully managed, hassle-free Schema Registry, which can significantly reduce operational overhead for teams that prefer a SaaS model.
  • Advanced Enterprise Features: The commercial versions of Confluent Platform offer advanced features like fine-grained Role-Based Access Control (RBAC) and schema validation on the broker side, which are critical for large, security-conscious organizations.

Disadvantages

  • Potential for Vendor Lock-in and Higher Costs: The most advanced and user-friendly features are part of the paid Confluent Platform subscription. This can lead to significant licensing costs and a deeper commitment to the Confluent ecosystem, making future migrations more challenging.
  • More Limited Artifact Support: Confluent’s primary focus is on schemas for Kafka data (Avro, Protobuf, JSON Schema). It lacks the native, first-class support for other API artifacts like OpenAPI and AsyncAPI that Apicurio provides.
  • Less Flexibility in Deployment: The primary storage mechanism is a Kafka topic, offering less flexibility in terms of backend persistence compared to Apicurio’s support for PostgreSQL and other databases.
  • Restrictive Licensing: The Confluent Community License is more restrictive than the Apache 2.0 license of Apicurio, which can be a concern for some organizations.

Known Issues and Planned Solutions for Apicurio

As a mature and actively developed open-source project, Apicurio’s known issues and planned improvements are transparent and can be tracked through official documentation and community platforms. Here’s a summary of the known issues and the planned solutions based on the latest available information.

Known Issues in Apicurio

Known issues can be categorized into officially documented limitations in a specific release and bugs or feature enhancements reported by the community.

From the Official Red Hat Build of Apicurio Registry 3.0 Documentation:

The official release notes for the Red Hat build often list specific known issues for that version. As of early 2025, these include:

  • KafkaSQL Storage and Owner-Only Authorization: A specific issue where setting the owner-only-authorization property does not function as expected when using the KafkaSQL storage option. The current workaround is to not use this specific security feature with KafkaSQL.
  • Logout Incompatibility with RH-SSO 7.6: The logout feature in Apicurio Registry has a known incompatibility with Red Hat Single Sign-On (SSO) version 7.6.
  • Misleading Log Messages: A “warning” log message regarding a ResultSet resource leak may appear. This is a known incorrect message, and no resources are actually leaked. The official guidance is to safely ignore these specific warnings.
  • Operator Route Generation: When using the Apicurio Registry Operator on OpenShift, the autogeneration of the OpenShift route might occasionally use an incorrect base host value.

From Community and GitHub Issue Tracker:

The GitHub issue tracker provides a real-time view of user-reported bugs, enhancement requests, and ongoing discussions. Common themes for reported issues include:

  • Complex Schema Parsing: Issues are sometimes reported with the parsing of complex schemas, particularly those involving intricate references between different artifact types (e.g., Protobuf schemas with multiple dependencies).
  • UI Behavior with Large Artifacts: The web-based UI can sometimes experience rendering or performance issues when dealing with very large or complex schema artifacts.
  • Specific Authentication Scenarios: While Apicurio supports robust RBAC through OpenID Connect, users occasionally report issues with niche or complex authentication setups, such as certain proxy configurations or specific identity provider integrations.
  • Serializer/Deserializer (SerDes) Edge Cases: Users may encounter specific edge cases with the Kafka client SerDes modules, especially concerning memory management or behavior with less common data types.
  • Environment and Deployment Specifics: A number of issues are related to how Apicurio interacts with specific deployment environments, such as Istio service meshes or when deploying the operator in multiple namespaces.

Planned Solutions and Improvements

Apicurio’s roadmap is largely driven by the major themes of recent releases and active development on GitHub. The project focuses on continuous improvement and addresses known issues through regular updates and major version releases.

Red Hat Build of Apicurio Registry Roadmap

Recently Implemented Solutions (as of Apicurio 3.x):

The recent major release of Apicurio 3.0 addressed several long-standing “issues” or limitations of the 2.x versions and represents the current direction of the project:

  • Consistent Configuration Model: Apicurio 3.0 introduced a completely redesigned and more consistent configuration model, moving away from the previous, sometimes confusing, mix of registry.* and quarkus.* properties. This simplifies deployment and management.
  • Evolved and Flexible SerDes Modules: The serialization and deserialization modules were significantly refactored in version 3.x for better flexibility, reusability, and broader integration capabilities.
  • Improved REST API and SDKs: The Core REST API was updated in version 3.0 with new features and a more streamlined design. The project also adopted Kiota for automated SDK generation across multiple languages, improving the developer experience.
  • Enhanced Versioning and Governance: To provide more powerful governance, Apicurio 3.0 introduced support for artifact branching and semantic versioning. This allows for more sophisticated lifecycle management of schemas.

Future Improvements and Direction:

While a formal long-term roadmap with specific release dates for features is not typically published, the active development on GitHub and community discussions indicate the following areas of focus:

  • Ongoing Bug Fixes: The most direct way to track planned solutions for specific bugs is through the Apicurio Registry GitHub Issues. The development team actively triages, comments on, and resolves reported issues. Fixes are regularly included in minor and patch releases.
  • Enhanced AI-Powered Features: Recent blog posts and discussions suggest an interest in leveraging AI for schema-related tasks, such as AI-powered schema generation from payloads and natural language explanations for compatibility rules.
  • Deeper GitOps Integration: There is ongoing community interest and discussion around deeper integration with GitOps workflows, potentially allowing artifacts to be stored and managed directly in Git repositories.
  • Operator and Deployment Enhancements: The Apicurio Registry Operator is continuously improved to support more advanced deployment configurations, better integration with cloud-native technologies like Istio, and broader platform support (e.g., ARM64 architecture).
  • Continuous Improvement of Core Features: Ongoing work focuses on improving the performance of the storage layer (both SQL and KafkaSQL), enhancing the user interface, and ensuring robust support for the latest versions of supported artifact types like OpenAPI and AsyncAPI.

Impact on Existing Infrastructure

The documentation emphasizes the flexibility and broad compatibility of Red Hat Application Services, of which Apicurio Registry is a component. Red Hat’s approach focuses on providing solutions that integrate seamlessly with various environments:

  • Red Hat Application Services allow for broad deployment across on-premise, private cloud, public cloud, and hosted cloud environments. They are designed to operate across multiple OS and hardware platforms.
  • Red Hat offers clear support guidance for using their products with untested 3rd-party environments, and will provide a level of support in such scenarios.
  • The licensing model for core editions is flexible, eliminating the need for additional purchases when moving between different deployment environments, operating systems, container platforms, or lifecycle phases during a subscription term.
  • Integration with OpenShift is seamless and native. The Red Hat Build of Apicurio is designed “OpenShift-first,” deployed and managed via an official Operator.
  • Integration with Confluent Schema Registry is typically handled as a migration. The goal is usually to replace, not permanently co-exist with, the Confluent registry. Apicurio makes this process remarkably smooth thanks to a built-in Confluent-compatible API layer, which acts as a “drop-in” replacement for your existing Kafka applications.

Migration Process

Part 1: Integration with OpenShift

This is the most straightforward part of the process.

  • Operator-Based Deployment: Red Hat provides an official Apicurio Registry Operator available in the OpenShift OperatorHub. This automates installation, updates, and lifecycle management, ensuring best practices for deployment on OpenShift are followed out-of-the-box.
  • Native OpenShift Components: The Operator leverages native OpenShift components for networking (Routes), storage (Persistent Volumes), and configuration (ConfigMaps, Secrets).
  • Unified Monitoring and Logging: Apicurio will integrate directly into the OpenShift monitoring and logging stack (Prometheus, Grafana, Loki), allowing you to manage it using the same tools you use for your other applications.
  • Security Integration: It is designed to integrate seamlessly with Red Hat Single Sign-On (RH-SSO) for robust Role-Based Access Control (RBAC), all of which can be managed within OpenShift.

Part 2: Integration with Confluent Schema Registry

This is less about direct, side-by-side integration and more about providing a smooth transition path away from Confluent. There are two primary strategies: Migration (Recommended) and Co-existence (Temporary).

The goal here is to fully replace Confluent Schema Registry with Apicurio. Apicurio is specifically engineered to make this as painless as possible.

Key Feature: The Confluent Compatibility API

Apicurio includes a compatibility API layer that fully emulates the Confluent Schema Registry API (up to version 7). This is the key to a low-impact migration. When you deploy Apicurio, it exposes its standard API (/apis/registry/v3) as well as the Confluent-compatible endpoint (e.g., /apis/ccompat/v7).

How the Migration Works:
  1. Deploy Apicurio on OpenShift: Use the Red Hat Operator to deploy an instance of Apicurio Registry.
  2. Export/Import Schemas: Export your existing schemas from the Confluent Schema Registry. Apicurio provides tooling (such as a command-line tool or import/export APIs) to import this data into its own storage backend.
  3. Reconfigure Kafka Clients (The “Drop-in” Step): This is the critical step. In your Kafka client applications (producers and serializers), you only need to change the configuration property for the schema registry URL.
  4. Because Apicurio’s ccompat endpoint understands the Confluent wire protocol, you do not need to change your existing Confluent SerDes libraries (KafkaAvroSerializer, KafkaProtobufSerializer, etc.) in your applications. This dramatically reduces the scope and risk of the migration.
  5. Test and Decommission: After thorough testing to ensure all applications are correctly registering and retrieving schemas from Apicurio, you can safely decommission your Confluent Schema Registry instance.
Advantages of this approach:
  • Provides a single source of truth for all schemas.
  • Unlocks Apicurio’s broader features (e.g., OpenAPI, AsyncAPI support) for all your teams.
  • Reduces operational overhead and potential licensing costs from running two systems.
Strategy 2: Co-existence (A Temporary or Phased Approach)

While not ideal long-term, you can run both registries in parallel.

How it Works:
  • Both Apicurio and Confluent Schema Registry run as independent services.
  • You configure each Kafka application to point to a specific registry. Team A’s applications might point to Apicurio, while a legacy service (Team B) continues to point to Confluent.
Challenges and Disadvantages:
  • Schema Duplication: You will likely need to duplicate schemas across both registries, creating a high risk of divergence and a “split-brain” scenario.
  • No Single Source of Truth: This makes governance and discovery extremely difficult. Which registry is the authoritative source for a given schema?
  • Increased Operational Complexity: You must maintain, monitor, and secure two separate systems.
  • Configuration Headaches: Managing which application points to which registry can become complex and error-prone.
  • This strategy is generally only recommended as a short-term, transitional phase during a larger migration project.

Resources: