Apicurio v2 and v3 Differences

This reference lists the Apicurio Registry versions in Axual Streaming 2.0.0, the registry API each Axual Platform release uses, the Confluent-compatible endpoint change, and the configuration and Kafka storage differences between Apicurio Registry v2 and v3.

Type

Reference

Goal

Look up what differs between Apicurio Registry v2 and v3, and which API each release uses.

Audience

Platform Operators planning the v3 upgrade, and application developers planning a move to the v3 client.

When to use

Use this reference when you plan the upgrade or a client change, or when a v2 setting has no obvious v3 equivalent.

Contents

The sections below cover each area in this reference:

Registry versions in Axual Streaming

Axual Streaming 2.0.0 ships both Apicurio Registry versions as separate dependency charts, so they can run side by side:

Registry Chart and version Image version Values key and toggle

Apicurio Registry v2

apicurio-registry 3.1.11

2.6.13.Ax1

apicurio-registry, global.apicurio.enabled (enabled by default)

Apicurio Registry v3

apicurio-registry-v3 0.1.0

3.3.0.Ax1

apicurio-registry-v3, global.apicurio-registry-v3.enabled (disabled by default)

Registry API by platform release

Apicurio v3 keeps serving the v2 API alongside its native v3 API. The registry server, the Axual governance plane (Platform Manager and Topic Browse) and your applications each move from the v2 API to the v3 API independently, on different schedules:

Platform version Apicurio server Platform Manager and Topic Browse API Apps API

2026.1

v2

v2

v2

2026.2 (LTS)

v3

v2

v2 (stable) or v3 (beta)

2026.3

v3

v2

v2 (stable) or v3 (beta)

2026.4

v3

v3

v2 or v3 (both stable)

2027.1

v3

v3

v2 or v3 (both stable)

2027.2 (LTS)

v3

v3

v2 (deprecated) or v3 (stable)

In 2026.2 and 2026.3 the server is v3, but Platform Manager and Topic Browse keep calling its v2 API through the /apis/registry/v2 path in the Schema Registry URL, and applications keep using their v2 clients.

Confluent-compatible (ccompat) endpoint

Applications that use the Confluent-compatible API are the one client-side exception to the API compatibility above:

  • Apicurio v3 removes /apis/ccompat/v6 and serves only /apis/ccompat/v7.

  • Apicurio v2 already serves /apis/ccompat/v7, so a client on the v7 URL works against both versions.

  • The native registry API is unaffected: v3 keeps serving it at /apis/registry/v2.

Clients on /apis/ccompat/v6 must change to /apis/ccompat/v7 before the ingress switch; see How to Migrate Schemas to Apicurio v3.

Configuration differences

The table below lists the configuration and deployment differences between Apicurio v2 and v3:

Area Apicurio v2 Apicurio v3

Configuration property prefix

registry.*

apicurio.*

Environment variables

REGISTRY_*

APICURIO_*

Container image

apicurio-registry-kafkasql (Axual fork)

apicurio/apicurio-registry (official upstream)

Web UI

Bundled in the registry container

Separate container (apicurio-registry-ui)

Ingress

Single ingress block

Split into ingress.backend (API) and ingress.ui (UI)

Kafka storage

A single compacted topic

Three separate topics (journal, snapshots, events)

Consumer group prefix

apicurio-registry-

apicurio-

Kafka topics

Where v2 used a single compacted topic, v3 uses three. The chart’s init container creates all three, together with the ACLs (Access Control Lists) for the Apicurio principal, and their names are configurable:

Values key Purpose

kafka.journalTopic

Schema data journal

kafka.snapshotsTopic

Periodic data snapshots

kafka.eventsTopic

Change-event notifications

The default consumer group prefix also changes from apicurio-registry- to apicurio-; the init container handles this.