The best Kafka tool for teams running ksqlDB themselves is one that decides per person who may query a table, create a stream, insert rows or terminate a query, records which person ran each statement when the brokers only see the ksqlDB server’s own Kafka user, follows every source and persistent query to its topics, schema and consumer group, reaches several ksqlDB servers over TLS and basic authentication, and runs as one container beside the cluster, out of the data path. Kpow, Kafbat UI, AKHQ, the ksqlDB CLI and REST API, Confluent Control Center and Conduktor each cover part of that, and NORD/LB is one bank that moved its ksqlDB query development into Kpow. Scored on the six weighted criteria explained below the rankings, Kpow ranks first with 99 out of 110, ahead of Kafbat UI at 70 and AKHQ at 62; Conduktor, listed last, totals 65.
Tools compared
| Rank | Tool | Total (out of 110) | Out of the data path | Production access on request | Audit trail per person | ksqlDB operations | Directory and Kafka sign-in | Many teams, shared clusters | Cost a year, one cluster (modelled) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Kpow | 99 | One container, no external database, not a proxy | Query, execute, insert and terminate permissions; temporary policies | Every ksqlDB statement and query, by user | Sources, queries, lineage, consumer group links, editor, inserts | SAML, OpenID, LDAP | Tenants per team, ksqlDB included | $7,380 |
| 2 | Kafbat UI | 70 | One container | Read-only clusters, no approvals | Opt-in log, no view in the product | One server per cluster, one execute permission | OAuth2, OIDC, LDAP | Roles per resource | $8,640 |
| 3 | AKHQ | 62 | One container | Group roles, no approvals | Opt-in topic, no reads | Several servers, read and execute roles | LDAP, OIDC | Regex groups | $8,640 |
| 4 | The ksqlDB CLI and REST API | 54 | Nothing to deploy | Anyone who reaches the server | Command topic, no person | Every statement, nothing watching | HTTPS and basic auth at the server | One service ID per cluster | $11,520 |
| 5 | Confluent Control Center | 51 | Dedicated host plus a metrics reporter on each broker | Confluent RBAC, no approvals | Principal-level audit logs (licensed) | Editor, persistent queries, Explain, Flow View | OIDC | Admin access only, per TD Bank | $2,880 plus a quoted Confluent Platform subscription |
| 6 | Conduktor | 65 | Console on PostgreSQL; Gateway, a proxy, for data-level controls | Masking exemptions, owner approval | 70+ event types in the UI | Clusters, sources, queries, push and pull editor | LDAP, OIDC | Groups; Virtual Clusters need Gateway | $32,880; $122,880 with Gateway Core and Protect |
The tools, ranked for ksqlDB (self-managed)
Rank 1 Kpow
99 out of 110 Total
Try Kpow in the live demo No signup needed.
- Cost a year
- $4,500 per Kafka cluster with 100 users included, plus about $2,880 in operator time, so $7,380 on one cluster (modelled)
- On ksqlDB
- Several ksqlDB servers per Kafka cluster, over TLS and basic authentication; a Kpow Enterprise feature
- 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
- ksqlDB operations ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Directory and Kafka sign-in
- 9 out of 10
- Many teams, shared clusters
- 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 reaches ksqlDB through the ksqlDB REST API and Kafka as an ordinary client, so nothing sits between your queries and the brokers.
- Production access on request 9 out of 10
- ksqlDB actions are split into query, execute, insert and terminate permissions per ksqlDB server, temporary policies grant time-boxed access that an admin or a change system calling the Kpow API can create, staged mutations hold changes for approval, and data policies mask fields in inspection and in ksqlDB query results, though masking is per resource rather than per viewer.
- Audit trail per person 9 out of 10
- Every ksqlDB action, from a SELECT to a CREATE TABLE or a terminated query, is recorded with the user from the identity provider and the policy that allowed it, 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.
- ksqlDB operations 9 out of 10
- Sources and persistent queries sit in one view with each source’s columns, CREATE statement, schema and the queries that read from it and write to it, each query links to its sink topic and its consumer group for lag, the editor runs pull queries and statements with autocomplete and history, rows are inserted by hand or from CSV, JSON or EDN files, and queries are terminated from the same view; it is held below 10 because Control Center, the console from ksqlDB’s own vendor, adds a Flow View of the topology and the query execution plan.
- Directory and Kafka sign-in 9 out of 10
- People sign in with SAML, OpenID or LDAP, and Kpow connects to Kafka with the same SASL or TLS settings as any client and to each ksqlDB server over TLS, with a keystore for client certificates and HTTP basic authentication where the server requires it.
- Many teams, shared clusters 9 out of 10
- Tenants scope each team to its own topics, consumer groups and ksqlDB sources and queries on a shared cluster, and hide the ksqlDB menu from a tenant that has none, and RBAC adds Allow, Deny or Stage per action.
On ksqlDB. Kpow’s ksqlDB configuration connects to a ksqlDB server with KSQLDB_HOST and KSQLDB_PORT through the standard REST API, takes TLS, keystore, truststore and basic authentication settings, lists several ksqlDB servers for one Kafka cluster with KSQLDB_RESOURCE_IDS, and links each server to a schema registry with KSQLDB_SCHEMA_REGISTRY. Its ksqlDB management page covers source and query management, SQL execution and record insertion. The ksqlDB UI arrived in Kpow 91.1.
Where it falls short. It has no Flow View of a ksqlDB application’s topology and no query execution plan view, both of which Control Center has. Its SQL editor is documented for pull queries and statements, and pull query results are capped at 100 rows by default. Kpow governs people working through Kpow, so the ksqlDB REST API stays open to anyone the server itself lets in. ksqlDB management, RBAC, masking, staged mutations and the full audit log need Kpow Enterprise; Community Edition is free for 3 clusters and 10 users.
Rank 2 Kafbat UI
70 out of 110 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- On ksqlDB
- One ksqlDB server per Kafka cluster, basic support, free
- 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
- ksqlDB operations ×2 weight, this criterion counts 2 times toward the total
- 5 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 6 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.
- ksqlDB operations 5 out of 10
- Its configuration takes one ksqlDB server per Kafka cluster, with basic authentication and a keystore, the Kafbat UI review records basic ksqlDB support, and its RBAC has a single permission for ksqlDB, execute, so a role that can run a query can also drop a stream.
- 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.
- Many teams, shared clusters 6 out of 10
- Roles scope permissions per resource and list the clusters they apply to, with no tenant view of a team’s own resources.
On ksqlDB. Kafbat UI sets a ksqlDB server for each Kafka cluster with KAFKA_CLUSTERS_0_KSQLDBSERVER, plus basic authentication and keystore settings, in its configuration properties. Its RBAC documentation lists ksql as a resource with one action, execute. The Kafbat UI review covers the rest.
Where it falls short. One ksqlDB server per Kafka cluster means a second ksqlDB cluster on the same Kafka needs a second cluster entry, and the single execute permission cannot separate reading a table from terminating a query. There is no way to grant production access for an hour and have it expire or to hold a change for approval. Its modelled running cost on one cluster is 6 engineer-hours a month, $8,640 a year at $120 an hour.
Rank 3 AKHQ
62 out of 110 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- On ksqlDB
- A list of ksqlDB servers per connection, basic support
- 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
- ksqlDB operations ×2 weight, this criterion counts 2 times toward the total
- 5 out of 10
- Directory and Kafka sign-in
- 6 out of 10
- Many teams, shared clusters
- 5 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.
- ksqlDB operations 5 out of 10
- It takes a list of ksqlDB servers under each Kafka connection with basic authentication, and its roles split ksqlDB into read and execute, but the AKHQ review records a reported issue where ksqlDB did not appear in the menus despite correct configuration, and no link from a query to its consumer group is described.
- 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.
- Many teams, shared clusters 5 out of 10
- Groups combine resource types with regex patterns on names and clusters, which limits what a role can reach, but there is no tenant view of a team’s own resources.
On ksqlDB. AKHQ’s connection configuration takes an optional list of ksqlDB servers per Kafka connection, each with a name, a URL and basic authentication, and its roles grant READ and EXECUTE on the KSQLDB resource. 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 its ksqlDB support is the thinnest part of the product according to the review. 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 The ksqlDB CLI and REST API
54 out of 110 Total
- Cost a year
- $0 licence, about $11,520 in operator time (modelled)
- On ksqlDB
- The API every tool on this page calls
- Security default
- HTTP with no authentication until the server is configured
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 10 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 1 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- ksqlDB operations ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Directory and Kafka sign-in
- 4 out of 10
- Many teams, shared clusters
- 2 out of 10
Why these scores for The ksqlDB CLI and REST API
- Out of the data path 10 out of 10
- There is nothing to deploy beyond the ksqlDB servers themselves, which is the only option here that scores 10.
- Production access on request 1 out of 10
- Basic authentication with roles decides who can reach the server, not which statements they may run, so anyone let in can drop a stream or terminate a query, with no approval step, no expiring grant and no masking.
- Audit trail per person 2 out of 10
- The command topic stores every statement the cluster runs so that servers can rebuild them, which is a replay log rather than a record of who sent each one, and nothing ties a call to a person in the directory.
- ksqlDB operations 6 out of 10
- It has every statement, including EXPLAIN, TERMINATE and DESCRIBE, but nothing watches query state or lag, and each ksqlDB cluster is a separate target for the CLI or a script.
- Directory and Kafka sign-in 4 out of 10
- The server can serve HTTPS with client certificates and check basic authentication through a JAAS login module, which can be backed by LDAP, but there is no SAML or OpenID sign-in.
- Many teams, shared clusters 2 out of 10
- One ksqlDB cluster is one service ID with one Kafka user, and nothing marks which team owns which stream, table or query.
On ksqlDB. The ksqlDB CLI and the REST API behind it are how ksqlDB is meant to be run, and every UI on this page is a client of that API. The ksqlDB security documentation covers HTTPS, basic authentication with roles and the Kafka ACLs the server’s own Kafka user needs.
Where it falls short. It is a toolkit, not a tool: lag has to be read from each query’s consumer group elsewhere, failures noticed in the processing log, and access split by hand across servers, and anyone who can reach the API can run any statement unless the server is secured. Its modelled running cost is 8 engineer-hours a month, $11,520 a year at $120 an hour.
Compare ksqlDB on Kafka
Rank 5 Confluent Control Center
confluent.io
51 out of 110 Total
- Cost a year
- $2,880 operator time, plus a Confluent Platform subscription that is quoted (modelled)
- On ksqlDB
- Editor, streams, tables, persistent queries and Flow View
- 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
- ksqlDB operations ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Directory and Kafka sign-in
- 5 out of 10
- Many teams, shared clusters
- 4 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 the Confluent Metrics Reporter 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.
- ksqlDB operations 9 out of 10
- It is the console from ksqlDB’s own vendor, with a ksqlDB clusters page, an editor, streams and tables, persistent queries with Explain and Terminate, and a Flow View of the cluster’s topology, level with Kpow on this criterion, though it reaches ksqlDB on Confluent Platform only.
- 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.
- Many teams, shared clusters 4 out of 10
- TD Bank’s platform team said in its talk that Control Center could only accept admin access and was not scalable for their clients, which is why those clients moved to Kpow.
On ksqlDB. Control Center is the console Confluent ships with Confluent Platform. Confluent’s Control Center documentation for ksqlDB describes running queries on one or more ksqlDB clusters, each set with confluent.controlcenter.ksql.<name>.url, an editor, streams and tables pages, a persistent queries page with Explain and Terminate, and a Flow View of the topology, with Confluent RBAC deciding who can view and use ksqlDB. The Control Center review covers the rest.
Where it falls short. It reaches Confluent Platform clusters only, so a team that adds Confluent Cloud or moves to open-source Kafka needs a second tool. It offers no approval step or expiring grant, SAML is not available on self-managed deployments, and it is not sold separately and its price is not published.
Compare Kpow vs Confluent Control CenterConfluent Control Center review
Rank 6 Conduktor
conduktor.io
65 out of 110 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 ksqlDB
- Clusters, streams, tables, queries and an editor
- 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
- ksqlDB operations ×2 weight, this criterion counts 2 times toward the total
- 7 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 7 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.
- ksqlDB operations 7 out of 10
- Conduktor’s ksqlDB documentation describes a list of ksqlDB clusters, streams and tables with the queries that write to them, a queries tab that marks persistent and push queries, a Terminate button on streams and tables, and an editor that runs push and pull queries and statements, with RBAC restricting access per cluster; no link from a query to its consumer group and no row insert from a file is described.
- 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.
- Many teams, shared clusters 7 out of 10
- Permissions are set per user or group across clusters, but a user in several groups inherits the most permissive grant, and Virtual Clusters for multi-tenancy need Gateway.
On ksqlDB. Conduktor’s Console documentation for ksqlDB describes a home page listing the configured ksqlDB clusters, streams and tables tabs that show each source’s fields and source statement, a queries tab with each query’s output topic and type, and an editor that sends push and pull queries to the /query-stream endpoint. The Conduktor review covers the rest.
Where it falls short. Console 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, and a ksqlDB server is a Kafka client too, so routing it through Gateway puts Gateway in front of every query’s reads and writes. 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 vs Confluent Control CenterConduktor review
What teams using ksqlDB (self-managed) need
This page is about tools that sit beside ksqlDB when a team runs the ksqlDB servers itself, whether from the Confluent Platform packages, Confluent’s Kubernetes operator or the standalone ksqlDB images, against its own Kafka. ksqlDB is the streaming SQL engine for Kafka: it turns SQL statements into stream processing that runs continuously on the ksqlDB servers, as the ksqlDB documentation describes, and it is source-available under the Confluent Community License rather than Apache 2.0. What ksqlDB is and where it stands is covered in ksqlDB on Kafka, the wider Confluent stack in the best Kafka management tools for Confluent Platform, and the broader field of Kafka tools in the best Kafka management tools. Lenses and Redpanda Console are not ranked here, because their reviews on this site list no ksqlDB support.
A common failure is a persistent query that is running and producing nothing. ksqlDB writes every row it fails to process, a deserialization error after a producer changes format for example, to a separate record called the processing log, and by default those entries leave out the row data, so the query looks healthy while its output topic stays empty. The processing log can be written to a Kafka topic, and once it is, it is read like any other topic. The second signal is lag. ksqlDB is built on Kafka Streams, as how ksqlDB works explains, and each persistent query runs as its own Streams application, whose application.id is also the consumer group it reads through, per the Kafka Streams configuration reference. A query falling behind therefore shows up as consumer group lag on its source topics, which any tool that links a query to its group can show.
Out of the data path. A ksqlDB server is already a Kafka client that reads source topics and writes sink topics on every query’s behalf. A tool whose controls work only when client traffic passes through a proxy therefore sits in front of those reads and writes as well as the applications’, and a persistent query that feeds a downstream service then depends on the proxy staying up. A management tool needs nothing more than the ksqlDB REST API and a client connection to Kafka. Kpow is one container with no external database, installed in your own environment and out of the data path. 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.
Production access on request. ksqlDB’s own access control works at the door, not per statement. The ksqlDB security documentation says the server uses HTTP by default, and its basic authentication offers role-based authorization “by specifying which roles can access the ksqlDB server”, so a person who is let in can run a pull query, drop a table or terminate the persistent query another team depends on. Terminating a query stops it outright, and ksqlDB will only drop a source once the queries and sources that depend on it have been terminated or dropped first. What a tool adds on top is per person and per action: who may only read, who may create streams and tables, who may insert rows and who may terminate queries, plus access to production that expires after the task. Those controls are compared across the field in Kafka RBAC tools.
Audit trail per person. The same security page explains that on a cluster with ACLs, ksqlDB authenticates to Kafka as a single user and the ACLs are granted to that user. Every topic a query creates and every record it writes therefore reaches the brokers under the server’s identity, whoever typed the statement, and the server’s command topic, which stores every statement the cluster runs so that servers can rebuild them, is built for replay rather than for recording who sent each one. The only record of which engineer created a stream, inserted rows or terminated a query has to come from the tool they used. The options are compared in Kafka audit logging tools.
ksqlDB operations. Day-to-day work on ksqlDB is reading sources and queries together: which persistent queries read a stream and which write to it, the statement that created each one, the schema behind it, and the consumer group and sink topic of every query. Push and pull queries behave differently in a UI. The ksqlDB queries documentation describes a push query as a subscription that keeps emitting results and a pull query as a lookup that returns once, so a tool needs a limit on what a query returns to the browser and a permission on stopping queries. Deployment mode matters as well. In headless mode the REST interface is not available and the server runs a fixed SQL file, which locks the set of persistent queries down; no UI can run statements against a headless server, and what remains visible is the topics and consumer groups those queries use.
Directory and Kafka sign-in. A ksqlDB tool holds two connections: to Kafka with whatever SASL or TLS settings the cluster requires, and to each ksqlDB server’s REST API over HTTPS, often with basic authentication or client certificates, and with the schema registry the ksqlDB server uses beside it. People then sign in through the company directory over SAML, OpenID Connect or LDAP, so a statement is tied to a named person rather than to a shared credential.
Many teams, shared clusters. A ksqlDB cluster is shared by default: every server with the same service ID joins the same cluster and shares its queries, as the server configuration reference describes for ksql.service.id. Each team needs its own view of its own streams, tables and queries, and permission to touch only those. Teams moving ksqlDB workloads to Flink SQL meet the same question on Flink, and the best Flink tools for self-managed Apache Flink compares the tools for that.
Kpow does not win on every point. Confluent Control Center, from ksqlDB’s own vendor, is level with it on ksqlDB operations and adds a Flow View of the topology and the query execution plan, and the ksqlDB CLI has every statement with nothing to deploy. Kpow governs people working through Kpow, so the ksqlDB REST API remains open to anyone the server itself lets in, and securing it stays a job for the server configuration.
Over the years, we've sort of reflexively gone for SQL again and again. And I'm not entirely sure that's the right approach for streaming. … I think it's a very leaky abstraction.
Derek Troy-West, Co-founder and CEO of Factor House
Who runs Kpow with ksqlDB (self-managed)
NORD/LB runs its Kafka on Confluent’s Kubernetes operator and develops its ksqlDB queries in Kpow, as its case study describes, alongside two-step authorization for production access. Kpow’s ksqlDB support is documented for self-managed ksqlDB servers and for Confluent Cloud’s hosted ksqlDB with an API key, and Factor House does not modify or extend Kafka and sells no Kafka distribution, so the same ksqlDB views work whichever Kafka sits underneath. For customer accounts on specific platforms, the Confluent Platform page carries NORD/LB and TD Bank, the Apache Kafka Connect page carries TD Bank’s connector work, and the self-managed Apache Kafka page carries Gmarket and Claritev.
Which customer shows which criterion
- Production access on request
- NORD/LB
- ksqlDB operations
- NORD/LB
- Directory and Kafka sign-in
- NORD/LB
-
NORD/LB
- ksqlDB operations
- Production access on request
- Directory and Kafka sign-in
- ksqlDB query development
- Confluent for Kubernetes
- Two-step authorization
The German regional bank runs its Kafka on Confluent’s Kubernetes operator, with more than 200 topics, and started out on Confluent Control Center before adding Kpow as a companion tool. NORD/LB develops ksqlDB queries for its stream processing and hit a 3,000-line query limit in its earlier interface; in Erik Schumann’s words, “Kpow doesn’t have this limitation, so we just switched the complete development of KSQL DB queries to Kpow.” Its case study describes two-step authorization, where people sign in to Kpow and then act through technical users with scoped permissions, and says Kpow halved the time its teams spend debugging.
Source: NORD/LB case study
How a team runs Kpow with ksqlDB (self-managed)
Installing it beside the servers. Kpow runs as one Docker container, a Java JAR or from the Helm charts, in the same network as the ksqlDB servers. It needs no external database, because its snapshots, metrics and audit log live in topics on the Kafka cluster. ksqlDB management is a Kpow Enterprise feature.
Connecting the ksqlDB servers. Each ksqlDB server is added with KSQLDB_HOST and KSQLDB_PORT, with KSQLDB_USE_TLS, a keystore and truststore for an HTTPS endpoint, and KSQLDB_BASIC_AUTH_USER and KSQLDB_BASIC_AUTH_PASSWORD where the server requires basic authentication. Several ksqlDB servers for one Kafka cluster, development and QA for example, are listed with KSQLDB_RESOURCE_IDS, and KSQLDB_SCHEMA_REGISTRY links a server to the schema registry it uses, so the ksqlDB views show each source’s Avro, Protobuf or JSON schema inline (ksqlDB configuration).
Reading sources and queries. The describe view of a stream or table shows its type, backing topic, format, columns and the exact CREATE statement, with the persistent queries that read from it and write to it, so the dependencies of a source are on one screen before anything is dropped. Each persistent query links to its SQL, its sink topic and the consumer group behind it, where lag shows whether the query is keeping up, and the ksqlDB view opens the records on a source’s topic through data inspect (ksqlDB management). A processing log written to a Kafka topic is an ordinary topic that data inspect can read.
Running SQL. The editor runs pull queries and ksqlDB statements such as CREATE STREAM, CREATE TABLE, DROP TABLE and INSERT INTO, with autocomplete, query history and SQL loaded from a file, and records are inserted by hand or imported from CSV, JSON or EDN files with the expected schema shown beside them. Pull query results are capped by KSQLDB_QUERY_MAX_ROWS, 100 rows by default, and queries time out after KSQLDB_TIMEOUT_MS, 30 seconds by default, so a query from the browser cannot run without bound (ksqlDB configuration).
Deciding who may do what. Kpow’s authorization actions split ksqlDB into KSQLDB_QUERY (push or pull queries), KSQLDB_EXECUTE (statements such as CREATE TABLE), KSQLDB_INSERT (rows into a stream or table) and KSQLDB_TERMINATE_QUERY, and RBAC sets Allow or Deny per action, with ksqlDB policies applied to specific ksqlDB servers, so analysts can query a production table without being able to terminate the query that maintains it. Query results pass through Kpow’s data masking policies. Tenants give each team a view limited to its own ksqlDB sources and queries, topics and groups, and a temporary policy grants extra access for a set time and then expires.
Signing people in. Engineers sign in through SAML, OpenID Connect or LDAP, so every ksqlDB statement carries a person from the company directory, even though the ksqlDB server reaches Kafka as one user.
Watching state and keeping the record. Kpow exports ksqlDB counts per server, including ksqldb_queries_count, ksqldb_streams_count and ksqldb_tables_count, to Prometheus (listed in the metrics glossary), so a query count that drops after a deployment is a one-line Alertmanager rule. The audit log records every ksqlDB action with the user from the identity provider, from a SELECT to a terminated query, 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 UI before you connect your ksqlDB servers
The live Kpow demo runs on two Apache Kafka clusters on Amazon MSK. It shows brokers, topics, consumer groups, schema registries and the __oprtr_audit_log topic where Kpow keeps its audit trail, with no signup. The demo has no ksqlDB server attached, so connecting your own ksqlDB servers is the step to try next.
For platform teams choosing a tool for ksqlDB.
Try the Kpow demoFAQ
What is the best tool for ksqlDB?
On this page’s rubric, Kpow, with 99 of 110 points: it splits ksqlDB permissions into query, execute, insert and terminate, records every statement against the person who ran it, follows each source and query to its topics, schema and consumer group, reaches several ksqlDB servers over TLS and basic authentication, and runs as one container beside the cluster with no external database. Kafbat UI is the highest-scoring free option, and Confluent Control Center is level with Kpow on ksqlDB operations alone.
Does Kpow support ksqlDB?
Yes, in Kpow Enterprise. Kpow connects to any ksqlDB server through its REST API with KSQLDB_HOST and KSQLDB_PORT, supports several ksqlDB servers per Kafka cluster, TLS and basic authentication (ksqlDB configuration), and also works with Confluent Cloud’s hosted ksqlDB. The ksqlDB UI arrived in Kpow 91.1.
Why is my ksqlDB query running but producing no output?
Check the processing log first. ksqlDB records every row a query fails to process there, a deserialization error for example, and by default leaves the row data out, so a query can run while its sink topic stays empty. Then check the lag of the query’s consumer group on its source topics. The processing log documentation covers writing it to a Kafka topic.
Is a self-managed ksqlDB server secure by default?
No. It serves its REST API over plain HTTP until it is configured for HTTPS, and its basic authentication decides which roles can reach the server rather than which statements each person may run, as the ksqlDB security documentation describes. Configure HTTPS and basic authentication on the server, grant the server’s Kafka user only the ACLs it needs, and give people per-action permissions in the tool they use.
Is there a free Kafka UI for ksqlDB?
Kafbat UI and AKHQ are open source and both take ksqlDB servers in their configuration, with basic support in Kafbat UI and reported problems in AKHQ. ksqlDB management in Kpow is an Enterprise feature; Kpow Community Edition is free on up to 3 clusters and 10 users for the rest of Kpow. More free options are compared in the best free Kafka UI tools.
How these tools were scored
Five of the six criteria are the ones Factor House scores on every page for teams that share a Kafka cluster; the sixth is ksqlDB operations. 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. The weights add up to 11, so totals are out of 110.
1. Out of the data path (counts three times). The tool should run in your own environment, reach Kafka as an ordinary client and ksqlDB through its REST API, and keep no data outside your own cluster. Scored lower: tools that need an external database or a dedicated host 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 a dedicated host and a component on every broker 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, which here is the ksqlDB CLI and REST API. 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 permissions separate reading from creating, inserting and terminating, whether a destructive change 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, queries 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. ksqlDB operations (counts twice). Whether the tool lists streams, tables and persistent queries with their statements and schemas, shows which queries read from and write to each source, links a query to its sink topic and consumer group, runs pull queries and statements with a limit on results, inserts rows, terminates queries, and reaches several ksqlDB servers.
5. Directory and Kafka sign-in (counts once). Whether people sign in through SAML, OpenID Connect or LDAP, and whether the tool connects to Kafka with the same SASL or TLS settings as any client and to the ksqlDB REST API over HTTPS with authentication.
6. Many teams, shared clusters (counts once). Whether each team can be given its own view of its own topics, consumer groups and ksqlDB sources and queries on a shared cluster, and whether one deployment reaches several clusters.
Costs are modelled for one production Kafka cluster with its ksqlDB servers 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, and the ksqlDB CLI and scripts carry 8 hours a month, $11,520. Kpow’s $7,380 uses the published price of $4,500 per cluster with 100 users included. Confluent Control Center is not sold separately and comes with a Confluent Platform subscription whose price Confluent quotes rather than publishes, so its total cannot be compared with the others here. 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, but ksqlDB management needs Kpow Enterprise. For free options compared at any team size, see the best free Kafka UI tools.
The criteria map onto ksqlDB’s design 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, ksqlDB operations counts twice, Directory and Kafka sign-in counts once and Many teams, shared clusters counts once, for a total out of 110. Out of the data path counts three times. A ksqlDB server is already a Kafka client that reads and writes on every query's behalf, so a tool whose controls work through a proxy sits in front of those reads and writes as well as the applications', and a tool that needs a database of its own is one more stateful service beside the ksqlDB servers. Production access on request, the per-person audit trail and ksqlDB operations count twice: ksqlDB's own authentication decides who reaches the server rather than which statements each person may run, and it authenticates to Kafka as one user, so who may terminate a query or drop a stream, and who did, has to come from the tool, and a tool that cannot follow a query to its consumer group and sink topic leaves the team in the CLI. Directory and Kafka sign-in, and shared clusters, 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 99 out of 110. The other options follow by total. Conduktor is listed last whatever its total; on its total of 65 it would place third.
Related reading
- Kafka: the complete guide
- ksqlDB on Kafka
- Best Kafka management tools for Confluent Platform
- Best Kafka tools for Apache Kafka Connect
- Best Kafka tools for self-managed Apache Kafka
- Best Kafka UI tools for Confluent Schema Registry
- Best Flink tools for self-managed Apache Flink
- Best Kafka management tools for banks