CMAK vs Lenses
ComparisonsCMAK vs Lenses, compared
Key takeaway
CMAK requires a direct ZooKeeper connection, and Kafka 4.0 runs KRaft only, so a cutover ends it the day it lands; its last release was April 2022, and both community deployment paths are archived. Lenses connects as an ordinary Kafka client, so KRaft is a non-event for it, but it is a control plane: PostgreSQL behind HQ, one Agent per cluster, and a database behind every Agent, with DevX Team starting at 4,000 US dollars a year. Kpow by Factor House is one stateless container, licensed per cluster.
What is CMAK?
CMAK is Cluster Manager for Apache Kafka, originally Kafka Manager, built at Yahoo and released under Apache 2.0. It is written in Scala on the Play framework, and its scope is administrative rather than data-plane. It sits with the other free Kafka UI tools rather than in the free tier of a commercial one: no commercial distribution, no hosted offering and no paid support tier.
- registering and monitoring clusters from a single view
- creating and modifying topics, and managing partitions
- partition reassignment and preferred-replica election
- optional JMX polling at broker and topic level
Everything else follows from one architectural fact: it requires a direct connection to a ZooKeeper ensemble to function at all. The last stable release, 3.0.0.6, was tagged 29 April 2022, and the last commit on master is December 2022. The repository is public and not archived, and it carries 11,925 stars and 2,476 forks.
What is Lenses?
Lenses is a commercial Kafka governance and data exploration platform that sits on top of clusters somebody else runs. It operates as a Kafka client and does not sit in the data path. The architecture is a central Lenses HQ node with lightweight Agents deployed one per cluster, and because an Agent connects as an ordinary Kafka client, a KRaft cluster needs no modification to be reached. Celonis acquired Lenses in early 2022, and 6.2.6 was released on 19 August 2026.
- SQL Studio: lets a reader query a Kafka topic without writing consumer code, over JSON, Avro or Protobuf.
- Topology and lineage: one picture across producers, topics, connectors and consumers in a multi-cluster estate.
- SQL Processors: Kubernetes-native stream processing built on Kafka Streams, with rules defined in SQL.
- Data catalogue: registered datasets grouped for search.
What is the official 2026 pricing of CMAK and Lenses?
CMAK costs nothing to license and there is no tier above it, so the whole cost is operator time: somebody builds it from Scala source, keeps a ZooKeeper ensemble reachable, and answers for it when it stops. There is no SLA to escalate to, because 522 issues stand open with no maintainer triaging them.
Lenses publishes two ladders, and a team can end up on both. DevX covers the UI, the governance surface and SQL, tiered by capability and user count: Community is free for up to 5 users on basic authentication, with no SSO and no role-based access; Team starts at 4,000 US dollars a year for up to 15 users and adds SSO, SAML, RBAC and team support; Multi-Kafka Enterprise is custom priced. K2K, the replication product, is metered separately, with Community capping a replication job at 5 topic partitions and Enterprise starting at 1,000 US dollars a month with 5 clusters included and further clusters at 200 US dollars a month. The change a CMAK operator is making is from a bill of zero to a bill attached to headcount and cluster count at the same time.
Where does each one run out?
CMAK cannot connect to a Kafka 4.0 cluster at all. It requires a direct ZooKeeper connection and Kafka 4.0 runs KRaft only. The maintainer acknowledged this in 2022 and nothing has shipped since. MSK, Confluent Cloud, Aiven and Redpanda Cloud either lock down or no longer expose ZooKeeper endpoints, and both community deployment paths are archived and read-only.
- Data plane: no message browsing, no Schema Registry integration and no Kafka Connect management.
- Access control: LDAP basic auth and global feature flags, with no per-topic granularity, no SAML, no OIDC and no audit log.
- Freshness: reads come from an internal cache and the broker view refreshes on a 30-second default.
- Longevity: long-running instances hang after 20 to 30 days on a thread-pool exhaustion error reported in 2018.
Credentials also pass unencrypted unless SSL is configured by hand, which is awkward inside any Kafka security architecture that has to be evidenced.
What Lenses costs is what its control plane asks a platform team to keep alive. HQ requires PostgreSQL and it is the only supported storage option. Each Agent needs its own database as well, with the embedded H2 route documented for evaluation only, and one Agent reaches one Kafka cluster, so a four-cluster estate is HQ plus a database plus four Agents plus four more databases.
- Availability: HQ runs a single replica, with no value exposed to change it and a default update strategy that replaces the pod rather than rolling it.
- Portability: SQL Processors are proprietary and compiled in Kubernetes, so a team that leaves takes its SQL and not the engine.
- Permissions: 6.2.5 split
UpdateTopicDetailsinto two actions, so custom RBAC for Kafka roles need re-granting by hand. - Masking: data policies match on field name across every registered dataset and are global, so masking cannot vary by role.
Which should you pick?
Keep CMAK if:
- the cluster is still on ZooKeeper with no migration scheduled
- the people using it already hold cluster credentials
- the daily work is partition reassignment and preferred-replica election
Take Lenses if:
- the people who need the data are not the people who run the cluster
- topology and lineage across a multi-cluster estate is the actual project
- SSO, SAML and role-based access are a procurement requirement
Replacing a working Kafka UI for its own sake is not a project, and CMAK’s case closes on a date rather than fading: the day the cluster moves to KRaft. Removing it then is cheap, because it holds no cluster state of its own. On the other side, what the money buys is a vendor and a data-access layer, and the counterweight belongs in the same breath: SQL Processors are the part you cannot take with you. Neither sits where a shortlist of the best Kafka management tools would put it, because the shortlist ranks features and the trade here is operator time.
Kpow: nothing else to keep alive
Both of these hand a platform team a second system to run before the first one does anything. CMAK needs a reachable ZooKeeper ensemble and a Scala build produced in-house, and Lenses needs PostgreSQL behind HQ as its only supported storage option plus a database behind every Agent, so a four-cluster deployment is HQ, four Agents and five databases before any topology renders. Kpow by Factor House is a single stateless JVM container configured entirely through environment variables, with no external database, sidecar or persistent volume: it keeps its own telemetry in internal Kafka topics on the cluster it is watching, and reaches up to 12 clusters from that one instance. It is licensed per cluster at a published price.
A tool you have to keep alive is a second job. Kpow’s product page has the full specification and the published price for the one that doesn’t need it.