Best Kafka UI tools for Confluent Schema Registry
ComparisonsThe best Kafka UI tool for Confluent Schema Registry is one that connects to the registry the way Confluent Platform or Confluent Cloud secures it, decodes and produces records with the same serialisers and data contract rules as the applications, lets only permitted people change a subject’s compatibility, keeps an audit trail that names each person, holds more than one registry when a team has them, and runs as one container beside the cluster, out of the data path. TD and NORD/LB, both Confluent users, run Kpow for their schema work. Kpow, Kafbat UI, AKHQ, Lenses, Redpanda Console, Confluent Control Center and Conduktor each cover part of that. Scored on the six weighted criteria explained below the rankings, Kpow ranks first with 91 out of 100, ahead of Kafbat UI at 65 and AKHQ at 57; Conduktor, listed last, totals 56.
Tools compared
| Rank | Tool | Total (out of 100) | Out of the data path | Production access on request | Audit trail per person | Directory and Kafka sign-in | Multiple registries | Confluent registry depth | Cost a year, one cluster (modelled) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Kpow | 91 | One container, no external database, not a proxy | Temporary policies, staged approvals, masking | Every action and data read, by user | SAML, OpenID, LDAP | Several registries of any kind per cluster (Enterprise) | Basic, mTLS, OAuth; references; data rules; diff | $7,380 |
| 2 | Kafbat UI | 65 | One container | Read-only clusters, no approvals | Opt-in log, no view in the product | OAuth2, OIDC, LDAP | One per cluster | Basic, OAuth, mTLS; no references or rules documented | $8,640 |
| 3 | AKHQ | 57 | One container | Group roles, no approvals | Opt-in topic, no reads | LDAP, OIDC | One per cluster | Basic, TLS properties; Avro references | $8,640 |
| 4 | Lenses | 50 | HQ on PostgreSQL plus an agent per cluster | Global masking, no approvals | In-product audit log | SSO from Team tier | One per environment | Connected; details not published | $6,880 for 15 users; custom above |
| 5 | Redpanda Console | 47 | One container | None in the free build; RBAC licensed | No record on non-Redpanda brokers | OIDC (Enterprise) | One per deployment | Basic, bearer token, client TLS | $8,640 plus an unpublished licence for sign-in and RBAC |
| 6 | Confluent Control Center | 40 | Dedicated host, broker reporter JAR | Confluent RBAC, no DENY, no approvals | Server audit logs name the principal | OIDC on self-managed | Confluent Platform only | Native view and diff; Platform only | $2,880 plus a quoted Confluent Platform subscription |
| 7 | Conduktor | 56 | Console on PostgreSQL; Gateway, a proxy, for data-level controls | Masking exemptions, owner approval | 70+ event types in the UI | LDAP, OIDC | One per cluster | Basic, bearer, mTLS; compatibility check and compare | $32,880; $122,880 with Gateway Core and Protect |
The tools, ranked for Confluent Schema Registry
Rank 1 Kpow
91 out of 100 Total
Try Kpow in the live demo No signup needed.
- Cost a year
- $4,500 per cluster with 100 users included, plus about $2,880 in operator time, so $7,380 on one cluster (modelled)
- On Confluent Schema Registry
- Basic auth, mTLS and OAuth; schema references; data contract rules in data inspect
- Deployment
- One container or JAR, no external database
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Directory and Kafka sign-in
- 9 out of 10
- Multiple registries
- 10 out of 10
- Confluent registry depth
- 9 out of 10
Why these scores for Kpow
- Out of the data path 9 out of 10
- It is one container or JAR whose snapshots, metrics and audit log live in topics on your own cluster, and it reads the registry over its REST API like any client, so nothing sits between your applications and the brokers or the registry.
- Production access on request 9 out of 10
- Temporary policies grant time-boxed access that an admin or a change system calling the Kpow API can create, staged mutations hold any action for approval, and data policies mask fields in inspection, though masking is per resource rather than per viewer.
- Audit trail per person 9 out of 10
- Every action is recorded with the user from the identity provider and the policy that allowed it, including data inspect queries, with a seven-day view in the product, the record written to an audit topic on your own cluster, and webhooks that send it to a SIEM for long-term retention.
- Directory and Kafka sign-in 9 out of 10
- People sign in with SAML, OpenID or LDAP, and Kpow connects to the brokers with the same SASL or TLS settings as any Kafka client.
- Multiple registries 10 out of 10
- Several registries of different kinds can be attached to one Kafka cluster with
SCHEMA_REGISTRY_RESOURCE_IDS, Confluent beside Apicurio, Karapace, AWS Glue or Google’s registry, which no other UI here documents; more than one registry needs Kpow Enterprise. - Confluent registry depth 9 out of 10
- Its Confluent registry documentation covers basic authentication, mutual TLS and OAuth, release 93.3 added creating and editing schemas with references and producing and consuming with them, release 95.1 made data inspect run Confluent data contract rules and flag failures, and the features page lists a visual version diff and compatibility updates in both editions; Control Center remains Confluent’s own view on Confluent Platform.
On Confluent Schema Registry. Kpow connects to a registry with SCHEMA_REGISTRY_URL and, for basic authentication, SCHEMA_REGISTRY_AUTH, SCHEMA_REGISTRY_USER and SCHEMA_REGISTRY_PASSWORD (schema registry configuration). Its Confluent Schema Registry page adds keystore and truststore settings for mutual TLS and bearer settings for OAuth, including the logical cluster and identity pool IDs that Confluent Cloud requires. Release 93.3 brought schema references for Avro, JSON Schema and Protobuf, and release 95.1 added CEL, CEL_FIELD and JSONata data rules to data inspect. The Kpow features page lists Confluent Schema Registry in both Community and Enterprise editions.
Where it falls short. Kpow governs people working through Kpow; producers and consumers still call the registry with their own credentials, and the registry’s own access control remains the control for them. Data inspect runs data contract rules when reading, and the release notes do not describe writing or editing the rules themselves, which stays with Confluent’s tooling. More than one registry per cluster, RBAC, masking, staged mutations and the audit log need Kpow Enterprise; Community Edition is free for 3 clusters and 10 users and includes Confluent Schema Registry.
Rank 2 Kafbat UI
65 out of 100 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- On Confluent Schema Registry
- Basic auth, OAuth client credentials and mTLS documented
- Sign-in
- OAuth2, OIDC and LDAP, free
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Multiple registries
- 4 out of 10
- Confluent registry depth
- 7 out of 10
Why these scores for Kafbat UI
- Out of the data path 9 out of 10
- It is one stateless container with no database and no proxy, the same pass as Kpow.
- Production access on request 4 out of 10
- RBAC grants actions per resource and a cluster can be set read-only, but there is no approval step, no time-boxed grant, and its masking applies the same way to every viewer.
- Audit trail per person 6 out of 10
- Its audit log names the logged-in user and records reads when the level is set to ALL, but it writes to a topic or the console with no view in the product, so reading the trail is something you build.
- Directory and Kafka sign-in 7 out of 10
- It supports OAuth2 and OIDC, including Microsoft Entra ID, and LDAP or Active Directory, and its documentation does not list SAML.
- Multiple registries 4 out of 10
- It manages one registry per Kafka cluster, with extra registries only as deserializers, and many clusters per install.
- Confluent registry depth 7 out of 10
- Its configuration reference documents basic authentication, OAuth client credentials and a keystore for mutual TLS to the registry, and it edits schemas and compatibility, but schema references and data contract rules are not described in its documentation.
On Confluent Schema Registry. Kafbat UI attaches one registry to each cluster connection. Its configuration reference lists SCHEMAREGISTRYAUTH settings for a username and password or for OAuth client credentials (not both on one cluster), and SCHEMAREGISTRYSSL keystore settings for mutual TLS. The Kafbat UI review covers its RBAC and release history, including regressions that broke Schema Registry serde auto-selection.
Where it falls short. There is no way to grant production access for an hour and have it expire, no approval before a compatibility change or a subject deletion runs, and masking cannot exempt the team that owns the data. No vendor is under contract to ship fixes. Its modelled running cost on one cluster is 6 engineer-hours a month, $8,640 a year at $120 an hour.
Rank 3 AKHQ
57 out of 100 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- On Confluent Schema Registry
- Basic auth, TLS through client properties, Avro references
- Security default
- Disabled until you enable it
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 3 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Directory and Kafka sign-in
- 6 out of 10
- Multiple registries
- 4 out of 10
- Confluent registry depth
- 6 out of 10
Why these scores for AKHQ
- Out of the data path 9 out of 10
- It is one stateless container with no database and no proxy, the same pass as Kpow.
- Production access on request 3 out of 10
- Groups bind actions to resources by regex, but there is no approval step or time-boxed grant, masking is global, and without the JWT signing secret the restriction is in the UI only.
- Audit trail per person 4 out of 10
- Audit events are opt-in to a Kafka topic, reads are not recorded, and there is no view for the trail.
- Directory and Kafka sign-in 6 out of 10
- It supports LDAP, OIDC and header authentication from a proxy, does not list SAML, and ships with security disabled until you enable it.
- Multiple registries 4 out of 10
- It manages one registry per cluster connection, Confluent or TIBCO, with Glue for decoding only.
- Confluent registry depth 6 out of 10
- Its connection settings take a basic authentication user and password and pass TLS settings through the registry client’s properties, and its documentation describes registering Avro schemas with references, but OAuth to the registry, a version diff and data contract rules are not described.
On Confluent Schema Registry. AKHQ sets a schema-registry block on each cluster connection with a URL, basic-auth-username and basic-auth-password, and properties for the registry client, especially TLS (AKHQ cluster configuration). Its schema references page shows how to register an Avro schema that references another. The AKHQ review covers the rest.
Where it falls short. Security is off until you configure it, the audit trail is an opt-in topic that does not record reads, and there is no approval step or time-boxed grant. Its modelled running cost on one cluster is 6 engineer-hours a month, $8,640 a year at $120 an hour.
Compare Kpow vs AKHQAKHQ review
Rank 4 Lenses
lenses.io
50 out of 100 Total
- Cost a year
- Team is $4,000 for up to 15 users on one cluster, $6,880 with operator time; 25 engineers needs a custom quote (modelled)
- On Confluent Schema Registry
- Connected through the agent in each environment
- Deployment
- HQ on PostgreSQL plus an agent and database per cluster
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 4 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 7 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Multiple registries
- 4 out of 10
- Confluent registry depth
- 5 out of 10
Why these scores for Lenses
- Out of the data path 4 out of 10
- It runs a central HQ on PostgreSQL plus an agent and an agent database beside every cluster, and HQ has no high-availability option.
- Production access on request 4 out of 10
- Its masking is the strictest view-time model, global with no escape even for admins, but no approval step or time-boxed grant is described.
- Audit trail per person 7 out of 10
- Audit logs can be read in the product, with no need to build a consumer first.
- Directory and Kafka sign-in 7 out of 10
- SSO spans Okta, Keycloak, OneLogin, Google and Entra ID, with basic authentication only on Community.
- Multiple registries 4 out of 10
- Its agent connects to the Schema Registry of each environment, one registry beside each Kafka cluster, with many environments under one HQ.
- Confluent registry depth 5 out of 10
- The Lenses review records Schema Registry integration beside its own SQL, and this page found no public Lenses statement on OAuth or mutual TLS to the registry, schema references or data contract rules, so the fit is the reader’s to verify.
On Confluent Schema Registry. Lenses connects to a Kafka cluster and its registry through an agent in each environment, and SQL over topics is the centre of the product and the strongest query model on this page. The Lenses review covers its tiers and deployment.
Where it falls short. A central HQ on PostgreSQL plus an agent and an agent database for every cluster adds two databases beside a registry that needs none. The Team licence stops at 15 users on one cluster, so a larger team is on a custom quote.
Compare Kpow vs LensesLenses review
Rank 5 Redpanda Console
redpanda.com
47 out of 100 Total
- Cost a year
- $0 for the free build, about $8,640 in operator time (modelled); sign-in and RBAC need an unpublished Enterprise licence
- On Confluent Schema Registry
- Basic auth, bearer token and client TLS
- Clusters
- One broker cluster and one registry per deployment
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Directory and Kafka sign-in
- 4 out of 10
- Multiple registries
- 2 out of 10
- Confluent registry depth
- 6 out of 10
Why these scores for Redpanda Console
- Out of the data path 9 out of 10
- It is a self-hosted container with no database, the same pass as Kpow.
- Production access on request 2 out of 10
- The free community build has no access control of any kind, and RBAC needs a Redpanda Enterprise licence, with no approval step or time-boxed grant described.
- Audit trail per person 2 out of 10
- Redpanda’s audit log is a feature of Redpanda’s own brokers, so on a Confluent cluster Console keeps no record of who did what, with or without an Enterprise licence.
- Directory and Kafka sign-in 4 out of 10
- It connects to Kafka-compatible brokers over the standard SASL mechanisms, but OIDC sign-in for people requires an Enterprise licence and is its only single sign-on protocol.
- Multiple registries 2 out of 10
- Its configuration has one
schemaRegistryblock beside one broker cluster, so each deployment reaches one registry. - Confluent registry depth 6 out of 10
- Its configuration reference documents basic authentication, a bearer token and client certificates for the registry, a clean connection, but schema references, a version diff and data contract rules are not described.
On Confluent Schema Registry. Redpanda Console is Redpanda’s web console, source-available under the Business Source License, and it connects to Kafka-compatible brokers and Confluent-compatible registries as well as Redpanda. Its message viewer is quick, with an observer mode that reads a topic without joining a consumer group. The Redpanda Console review covers the licence terms in detail.
Where it falls short. Governance is bought from Redpanda, a broker vendor, even on a Confluent cluster: sign-in and RBAC need an Enterprise licence whose price is not published, and Redpanda’s audit log is a feature of its own brokers. Each deployment reaches one broker cluster and one registry.
Rank 6 Confluent Control Center
confluent.io
40 out of 100 Total
- Cost a year
- $2,880 operator time, plus a Confluent Platform subscription that is quoted (modelled)
- On Confluent Schema Registry
- Confluent's own console for its registry on Confluent Platform
- Scope
- Confluent Platform clusters only
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 4 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Directory and Kafka sign-in
- 5 out of 10
- Multiple registries
- 3 out of 10
- Confluent registry depth
- 8 out of 10
Why these scores for Confluent Control Center
- Out of the data path 4 out of 10
- It is not a proxy, but it needs a dedicated host of 4 cores, 8 GB and 200 GB and a metrics reporter configured on each broker.
- Production access on request 2 out of 10
- Access runs through Confluent RBAC role bindings, which have no DENY rules, and no approval step, time-boxed grant or masking is described.
- Audit trail per person 4 out of 10
- Confluent Server’s structured audit logs, which need the Confluent Enterprise License, record authorization decisions for the connection’s principal, which is not always the person behind a tool.
- Directory and Kafka sign-in 5 out of 10
- OIDC is the only single sign-on protocol on self-managed deployments, with users and groups from LDAP or OIDC through Confluent RBAC.
- Multiple registries 3 out of 10
- It is scoped to Confluent Platform, and its docs say nothing about registries outside it.
- Confluent registry depth 8 out of 10
- As Confluent’s own console it shows subjects and versions, flags an incompatible edit and has a version diff check box, under the same Confluent RBAC as the registry, but it reaches Confluent Platform only, and a Confluent Cloud registry is managed in the Confluent Cloud Console instead.
On Confluent Schema Registry. Control Center is the console Confluent ships with Confluent Platform, and the Control Center review records Schema Registry among the components it views natively, beside Kafka Connect, ksqlDB and Kafka Streams, with one software architect crediting its registry view with improving data quality. NORD/LB and TD both started on it.
Where it falls short. It reaches Confluent Platform clusters only, so a team whose registry runs on Confluent Cloud, or that keeps a second registry of another kind, needs another tool. It offers no approval step or expiring grant before a compatibility change, and SAML is not available on self-managed deployments. It is not sold separately and its price is not published.
Cost a year. $2,880 of engineering time on this page’s estimate, 2 hours a month at $120 an hour, on top of a Confluent Platform subscription that Confluent quotes rather than publishes, so the total cannot be compared with the others here.
Compare Kpow vs Confluent Control CenterConfluent Control Center review
Rank 7 Conduktor
conduktor.io
56 out of 100 Total
- Cost a year
- 25 Console seats at $1,200 is $30,000 plus $2,880 operator time, so $32,880; Gateway Core adds $60,000 and Gateway Protect, which carries encryption and masking, a further $30,000 (modelled)
- On Confluent Schema Registry
- Basic auth, bearer token and mTLS; one registry per cluster
- Deployment
- Console on PostgreSQL 13+; data-level controls through Gateway, a proxy
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 8 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Multiple registries
- 4 out of 10
- Confluent registry depth
- 8 out of 10
Why these scores for Conduktor
- Out of the data path 3 out of 10
- Console needs PostgreSQL 13 or later, and its encryption, data-level masking and Virtual Clusters only work when client traffic goes through Gateway, a proxy in the data path.
- Production access on request 6 out of 10
- Masking can exempt users or groups, which beats every other tool here on who sees unmasked data, and cross-team access requests are approved by the owning team, but no expiring grant is described and topic creation that passes policy is a direct API call.
- Audit trail per person 8 out of 10
- Console logs produce, consume and admin requests across more than 70 event types with user, IP and timestamp, browsable in the UI and exported as CloudEvents.
- Directory and Kafka sign-in 7 out of 10
- Its SSO configuration covers LDAP and OIDC, with guides for Okta, Entra ID and Keycloak, and does not describe SAML.
- Multiple registries 4 out of 10
- Its cluster reference takes one registry per Kafka cluster, with many clusters per Console.
- Confluent registry depth 8 out of 10
- Its registry connection takes basic authentication, a bearer token or a client certificate, its Console checks compatibility before a schema update and compares versions, and subject permissions separate create, delete and compatibility edits; Confluent’s own data contract rules are not described, as its data quality rules are its own.
On Confluent Schema Registry. Conduktor’s Console documentation describes creating subjects, changing compatibility per subject or globally, checking compatibility before an update and comparing schemas of one subject. Its resource reference documents a registry per Kafka cluster with BasicAuth, BearerToken or SSLAuth security. The Conduktor review covers the rest.
Where it falls short. Console connects to the registry directly and needs PostgreSQL. Conduktor’s data-level controls, such as encryption, masking of the data itself and virtual clusters for multi-tenancy, run in Gateway, a Kafka proxy that client applications connect through. On AWS Marketplace, Conduktor Enterprise lists Console at $1,200 a seat for the first 100 seats, Gateway Core, which carries virtual clusters, at $60,000 a year, and Gateway Protect, the add-on for encryption and masking, at a further $30,000.
Compare Conduktor review
What teams on Confluent Schema Registry need
This page is about tools for a team that already runs Confluent Schema Registry, on Confluent Platform or on Confluent Cloud, and wants one UI for reading topics, managing subjects and governing who does what. It does not rank the registries themselves; Confluent’s registry, Apicurio, Karapace, AWS Glue and Redpanda’s are compared in the best tools for Kafka schema registry management. Teams on AWS Glue have their own page, the best Kafka UI tools for AWS Glue Schema Registry, and the wider Confluent picture is in the best Kafka management tools for Confluent Platform and the best Kafka UI tools for Confluent Cloud.
Out of the data path. Confluent Schema Registry is itself designed to stay out of the data path. Its serialisers plug into each producer and consumer, fetch the schema once and cache it, and, as Kai Waehner’s post on data quality with Schema Registry puts it, validation of schemas happens on the client side. A management tool fits that design when it is one more client: it reads the registry over REST, decodes records with the same serialisers, and sits in no application’s path. Kpow is one container with no external database, installed in your own environment and out of the data path; it keeps its working state in a few internal topics on the cluster, tuned to retain only a small amount of data, plus its audit log topic, the way Kafka’s design documentation describes log compaction letting a topic hold current state. Conduktor Console also connects directly, with a PostgreSQL database of its own; Conduktor’s data-level controls, such as encryption, masking of the data itself and virtual clusters, run in Conduktor Gateway, a Kafka proxy that client applications connect through.
A tool beside the registry can still load it. A registry with several thousand schemas costs a tool that reads each subject and version separately thousands of REST calls per snapshot, and the registry serves every producer and consumer too. Kpow’s default observation version reads every schema with its metadata in one call; the trade-off, stated in the same documentation, is that compatibility is then shown on each schema rather than in the list, and the older per-schema mode remains for registries that lack the bulk endpoint. The same page documents switching off start-up validation, so a tool restarted while the registry is unreachable shows an error for it and keeps retrying, rather than failing to start during the incident it is needed for.
Production access on request. On a registry, the risky actions are not only on topics. A compatibility mode set to NONE lets an incompatible schema through to every consumer of that subject, and a deleted subject breaks the producers that use it. TD’s platform team, which runs more than 300 projects on Kafka, still fields client teams that want their schema compatibility set to none and explains each time why that is not a good idea. What a team needs from the tool is a role that can read schemas but not change compatibility, an approval step before such a change runs, and production access for one task that then expires. In identity platforms the longest such grant is the organisation’s own setting, as Microsoft Entra Privileged Identity Management’s role settings show, and Kpow’s temporary policies let an administrator choose the expiry the same way. These controls are compared across the field in the best tools for Kafka role-based access control (RBAC).
Audit trail per person. The registry changes that matter most are few and easy to miss afterwards: a compatibility mode changed, a version deleted, a subject removed. Each needs a record of the person who made it, kept beside the record of who read which records in data inspect. NIST’s SP 800-53 gives audit and accountability a control family of its own, and the options are compared in the best tools for Kafka audit logging.
Directory and Kafka sign-in. The tool has to sign people in through the company directory and connect to the brokers and the registry with whatever each requires. On Confluent Platform the registry is often behind basic authentication or mutual TLS; on Confluent Cloud it takes an API key or an OAuth token from an identity pool. A tool that documents all of them avoids a shared static key held in its configuration.
Multiple registries. Teams end up with more than one registry for ordinary reasons: separate registries for development and production, a Confluent registry beside AWS Glue after an acquisition, or an old and a new registry during a migration. A tool that attaches one registry per cluster shows only one of them beside the topics they serve.
Confluent registry depth. Two features separate a tool that reads the registry from one that works with it. Schema references let one schema reuse another, so creating, editing and decoding a schema has to resolve them. Data contracts add rules to a schema, such as a field that must match a pattern, and Kai Waehner’s post describes them as an add-on available on Confluent Platform and Confluent Cloud. The rules run in the client serialisers, so a tool shows a record that fails its rules only if it runs the same rules when it reads; Kpow’s release 95.1 added that to data inspect. Producing test data is the third point: a tool that fetches the registered schema and serialises against it keeps malformed records out of a topic, which is how NORD/LB reduced incidents caused by bad schemas.
No tool here leads on every point: Control Center is Confluent’s own console and has the native view of the registry on Confluent Platform, and Lenses has the stronger query model with SQL over topics. Kpow governs people working through Kpow, so applications keep their own registry credentials and the registry’s own access control stays the control for them.
Who runs Kpow on Confluent Schema Registry
TD and NORD/LB both run Confluent, and both describe their schema work in Kpow in public. TD compares schema versions side by side in Kpow and gives each client team its own tenant, while its platform team holds the line on compatibility settings. NORD/LB produces test data through Kpow so that every record is serialised against the registered schema. Kpow’s supported registries, Confluent Schema Registry among them, are listed on the Kpow features page, and the same tool covers the rest of a Confluent deployment, as the Confluent Platform page and the Confluent Cloud page set out.
Which customer shows which criterion
- Production access on request
- TD Bank and NORD/LB
- Audit trail per person
- TD Bank
- Confluent registry depth
- TD Bank and NORD/LB
-
TD Bank
- Confluent registry depth
- Production access on request
- Audit trail per person
- On-prem and Confluent Cloud
- Schema version compare
- Compatibility requests
TD’s Event Streaming Platform runs more than 20 clusters, on-premises and on Confluent Cloud, with more than 300 projects onboarded and, in staff engineer Sandy Yang’s words, “many topics, partitions, and schemas”. Showing Kpow in her talk, she opens a subject and compares two versions of its schema, “here we have version 95 and version 94, and you can see clearly what was added.” She also names a request the platform team keeps declining: client teams that “want their schema compatibility set to none”, which the team has to explain, again and again, is not a good idea. Each onboarded team has its own Kpow tenant and access policy, and production inspect access is granted for an hour or two through the Kpow API.
-
NORD/LB
- Confluent registry depth
- Production access on request
- Confluent for Kubernetes
- Schema-aware produce
- Fewer schema incidents
The German regional bank runs its Kafka on Confluent’s Kubernetes operator, and its financial statement schemas run past 10,000 lines of JSON. Before Kpow, its test data tooling did not fetch the schema when producing, so malformed records reached its topics. Erik Schumann describes the change: “With Kpow, you aren’t able to produce bad data because Kpow always fetches the schema and serializes it with the actual schema, and with that you don’t get any issues.” The bank reports that the number of incidents associated with bad Kafka schemas decreased, and that two-step authorization lets it narrow what people can see in production.
Source: NORD/LB case study
How a team runs Confluent Schema Registry with Kpow
Installing it beside the cluster. Kpow runs as one Docker container, a Java JAR or through the Helm charts, in the same network as the brokers and the registry. It needs no external database, because its snapshots, metrics and audit log live in topics on the cluster itself.
Connecting to the registry. SCHEMA_REGISTRY_URL points Kpow at the registry, and basic authentication takes SCHEMA_REGISTRY_AUTH=USER_INFO with a user and password (schema registry configuration). A registry behind mutual TLS takes keystore and truststore settings, and one that expects OAuth takes bearer settings, including the logical cluster and identity pool IDs that Confluent Cloud requires (Confluent Schema Registry configuration). Setting SCHEMA_REGISTRY_STARTUP_VALIDATION=false lets Kpow start while the registry is down and reconnect when it returns.
Holding several registries. SCHEMA_REGISTRY_RESOURCE_IDS lists more than one registry for one Kafka cluster, each configured with its own prefix, such as DEV1_SCHEMA_REGISTRY_URL and QA2_SCHEMA_REGISTRY_URL, and the list order sets the order in the UI. A Confluent registry can sit beside Apicurio, Karapace, AWS Glue or Google’s managed registry this way; more than one registry needs Kpow Enterprise.
Managing subjects. The schema view lists each subject and version, creates and edits schemas, including schemas with references in Avro, JSON Schema or Protobuf, compares two versions in a visual diff and updates a subject’s compatibility, as the Kpow features page lists for both editions. RBAC sets Allow, Deny or Stage per schema action, so a team can read its subjects while a compatibility change or a deletion waits for approval through staged mutations.
Reading and producing records. Data inspect decodes Avro, JSON Schema and Protobuf records with the registry’s SerDes, follows schema references, runs data contract rules and lets engineers filter rule failures with kJQ. Data produce fetches the registered schema and serialises test records against it. Data policies mask sensitive fields in inspect results on the server.
Signing people in and granting access. Engineers sign in through SAML, OpenID Connect or LDAP, tenants give each team its own view of a shared cluster, and a temporary policy grants one role production access for a set time, which TD requests through the Kpow API from a service form.
Keeping the record. The audit log records each action, schema changes and data inspect queries included, with the user from the identity provider, and a webhook sends those records to Slack, Microsoft Teams or any HTTP endpoint, such as a SIEM collector.
Kpow live demo
See the Kpow schema view
The live Kpow demo runs on Apache Kafka clusters on Amazon MSK, and the registry attached to it is AWS Glue rather than Confluent. Open Schema to see the view a team gets on Confluent Schema Registry too: each subject with its version, compatibility mode and status, with no signup.
For platform teams choosing a Kafka tool for Confluent Schema Registry.
Try the Kpow demoFAQ
What is the best Kafka UI for Confluent Schema Registry?
On this page’s rubric, Kpow, with 91 of 100 points: it connects with basic authentication, mutual TLS or OAuth, handles schema references and data contract rules, compares versions and changes compatibility under per-person roles and approvals, holds several registries beside one cluster, and runs as one container with no external database. Kafbat UI is the highest-scoring free option.
Does Kpow support Confluent Schema Registry?
Yes. Kpow’s schema registry documentation names Confluent Schema Registry first among the registries it supports, its Confluent Schema Registry page covers mutual TLS and OAuth, and the Kpow features page lists it in both Community and Enterprise editions.
Does Kpow support schema references and data contracts?
Yes. Release 93.3 added creating and editing Avro, JSON Schema and Protobuf schemas with references and producing and consuming with them, and release 95.1 made data inspect run Confluent data rules of the CEL, CEL_FIELD and JSONata types and flag the records that fail them.
Can one Kafka UI manage several schema registries?
Kpow attaches more than one registry to a single Kafka cluster with SCHEMA_REGISTRY_RESOURCE_IDS, of the same or different kinds, in Kpow Enterprise. The other UIs on this page attach one registry to each cluster connection, and Control Center covers Confluent Platform only.
Does a Kafka UI need to sit in the data path to govern schema changes?
No. Kpow reads the registry over its REST API and applies roles, approvals and the audit trail to the people working through it, while producers and consumers keep calling the registry directly with their own serialisers. Conduktor Console also connects directly, while Conduktor’s data-level controls run in Gateway, a Kafka proxy that client applications connect through.
Is there a free Kafka UI for Confluent Schema Registry?
Kpow Community Edition is free on up to 3 clusters and 10 users and includes Confluent Schema Registry with the visual version diff. Kafbat UI and AKHQ are open source. Several registries per cluster, RBAC, masking, staged approvals and the audit log need Kpow Enterprise. More free options are compared in the best free Kafka UI tools in 2026.
How these tools were scored
Four of the six criteria are the ones Factor House scores on every page for teams that share a Kafka cluster; the other two are holding several registries and the depth of Confluent Schema Registry support. They are listed here in order of weight. Each criterion is scored 0 to 10: 10 where a tool is the only one here doing it or clearly the best, 8 for a clean documented pass, 5 or 6 for partial support or support that needs work the reader must verify, 1 to 4 for a weak or indirect form, and 0 where it is absent.
1. Out of the data path (counts three times). The tool should run in your own environment, reach the brokers and the registry over the same private network your applications use as an ordinary client, and keep no data outside your own cluster. Scored lower: tools that need an external database of their own, and tools whose controls work only when application traffic passes through a vendor’s proxy. A self-hosted container with no external database and no proxy scores 9, a tool with a database of its own 6, one with several databases, an agent per cluster or a dedicated host with a broker reporter 4, and one that needs both a database and a proxy for its controls 3; 10 is kept for an option with nothing to deploy at all, and none is scored here. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.
2. Production access on request (counts twice). Whether an engineer can be granted access to production for one task and have it expire, whether a destructive change, such as a compatibility change or a subject deletion, can be held for a second person’s approval, and whether sensitive fields can be masked from people who do not need them.
3. Audit trail per person (counts twice). Whether the tool records each action, reads included, against the person from the identity provider, and whether that record can be read in the product and sent to the systems that keep it long term.
4. Directory and Kafka sign-in (counts once). Whether people sign in through SAML, OpenID Connect or LDAP, and whether the tool connects to the brokers with the same SASL or TLS settings as any Kafka client.
5. Multiple registries (counts once). Whether one Kafka cluster can have more than one registry attached, of the same or different kinds, and whether one deployment reaches several clusters. These scores are the same as on the best tools for Kafka schema registry management for the tools scored on both pages.
6. Confluent registry depth (counts once). Whether the tool documents connecting to Confluent Schema Registry with basic authentication, mutual TLS and OAuth or a bearer token, handles schema references, runs data contract rules when reading, and compares versions and edits compatibility. A tool that connects but documents none of the rest scores 5.
Costs are modelled for one production cluster and 25 engineers at $120 per engineer hour, using the same hours per tool class as Factor House’s other comparison pages. Tools with a licence carry the published price plus 2 hours a month to run. The open-source UIs carry 6 hours a month, $8,640 a year, to run, secure and keep current. Kpow’s $7,380 uses the published price of $4,500 per cluster with 100 users included. Lenses publishes a Team price of $4,000 a year for up to 15 users on one cluster, so 25 engineers is a custom quote. Control Center is not sold separately, so its figure is operator time on top of a quoted Confluent Platform subscription. Conduktor’s Console is $1,200 a seat on AWS Marketplace, and its Gateway Core and Gateway Protect prices are added for the data-level controls; Conduktor prices Gateway per cluster with a 3-cluster minimum, and the listing does not say how many clusters that figure covers. Kpow Community Edition is free for 3 clusters and 10 users, so a 25-engineer team is on Enterprise. For free options compared at any team size, see the best free Kafka UI tools in 2026.
The criteria map onto Confluent Schema Registry’s features in the figure below.
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Out of the data path counts three times, Production access on request counts twice, Audit trail per person counts twice, Directory and Kafka sign-in counts once, Multiple registries counts once and Confluent registry depth counts once, for a total out of 100. Out of the data path counts three times. Confluent Schema Registry is built so that producers and consumers fetch schemas and check records in their own client libraries, with the registry beside the brokers rather than in front of them, and a tool that applications connect through, or that needs a database of its own, adds the component that design leaves out. Production access on request and the per-person audit trail count twice, because a registry change such as a compatibility mode set to NONE or a deleted subject reaches every producer and consumer of that subject. Directory sign-in, holding several registries, and the depth of Confluent Schema Registry support count once. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 91 out of 100. The other options follow by total. Conduktor is listed last whatever its total; on its total of 56 it would place fourth.
Related reading
- Kafka: the complete guide
- Best tools for Kafka schema registry management
- Best Kafka management tools for Confluent Platform
- Best Kafka UI tools for Confluent Cloud
- Best Kafka UI tools for AWS Glue Schema Registry
- Kpow vs Confluent Control Center
- NORD/LB case study
- Best Kafka governance tools for financial services