Kafdrop vs Lenses.io
ComparisonsKafdrop vs Lenses.io, compared
Key takeaway
Kafdrop and Lenses both put a web interface over a Kafka cluster somebody else runs, and the feature lists are not what separates them. Kafdrop is free under Apache 2.0 with no paid tier and no authentication inside the product, and a request for one closed as not planned, so protecting it means a proxy in front. Lenses is a commercial data platform: a central HQ node needing PostgreSQL plus an Agent database per cluster, with DevX Team from 4,000 US dollars a year for 15 users. Kpow by Factor House is licensed per cluster at a published price.
What is Kafdrop?
Kafdrop is an open-source Kafka UI built on Spring Boot and licensed Apache 2.0, hosted at obsidiandynamics/kafdrop. It runs as a stateless Java process talking standard broker protocols with no backend datastore, which is why it is the Docker Compose default in so many tutorials. It wants Java 17 or newer and Kafka 0.11.0 or newer, and takes Schema Registry as its one optional integration.
- view brokers and topics
- browse messages in JSON, plain text, Avro and Protobuf
- view consumer groups with combined and per-partition lag
- create topics, view ACLs, and reach Azure Event Hubs
Apache Kafka 4.0 supports KRaft only, and ZooKeeper mode has been removed. Kafdrop has needed no ZooKeeper connection since 3.10.0 and reads everything through the admin API, but three reports of the topic view failing against a KRaft cluster were each closed as not planned, the last in April 2025. Commits land continuously through August 2026, while the newest tagged release is 4.2.0 of July 2025.
What is Lenses?
Lenses is a commercial Kafka governance and data exploration platform that sits on top of clusters somebody else runs. It is a Kafka client rather than a proxy, so nothing of it sits in the data path, and it is owned by Celonis. A central Lenses HQ node sits alongside a lightweight Agent per cluster, and an Agent connects to one Kafka cluster at a time. KRaft clusters need no modification, because the Agent connects as an ordinary Kafka client. 6.2.6 shipped in August 2026.
- SQL Studio: a SQL interface for querying topics without writing consumer code.
- Topology and lineage: one view across producers, topics, connectors and consumers.
- SQL Processors: Kubernetes-native stream processing built on Kafka Streams.
- Roles: built-in Admin, Operator and Security Admin, with deletes and offset writes restricted to Admin.
What is the official 2026 pricing of Kafdrop and Lenses?
Kafdrop costs nothing to license: one tier, Apache 2.0, no commercial edition, no subscription and nobody to buy support from. The whole cost is operator time, and there is no SLA to escalate to.
Lenses is priced in two ladders. On the DevX side, Community is free for up to five users with Basic Auth only, no SSO and no RBAC. DevX 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. The step from Community to Team is a user-count step as well as a capability step, five to fifteen. Replication is metered separately: K2K Community is free with a maximum of five topic partitions per job, and K2K Enterprise starts at 1,000 US dollars a month with five clusters included and 200 dollars a month for each cluster after. At five engineers both are free and the question is what each exposes you to. At fifty, Kafdrop is still zero and Lenses is past both published user caps.
Where does each one run out?
Kafdrop has no authentication and no access control of any kind. The README says so plainly and documents an NGINX basic-auth workaround, and the feature request was opened in January 2026 and closed as not planned in February, so the absence is a settled scope statement.
- Write operations: exposed alongside the read ones, with no read-only mode. The pull request adding one has sat since November 2020.
- Reach: one cluster per deployment, no message search by key or value, and the deserialisation format set per topic by hand.
- Scale: roughly 1,010 topics and 2,000 partitions took over 30 minutes to load, with 5,566 consumer groups the dominant cost.
- ACLs: Kafka’s default authorizer holds them in cluster metadata, so a tool that displays them is not a tool that governs who may use it.
Lenses HQ is a single point in the current architecture. On the 6.2 chart line, HQ sets replicas: 1 as a literal, and the values file exposes no replica count, no autoscaling, no PodDisruptionBudget and no topology spread constraints, while it does expose an affinity block. The default update strategy is Recreate, so an upgrade terminates the running HQ before starting its replacement.
- Databases: PostgreSQL is the only supported store for HQ, each Agent needs one of its own, and Community carries the same dependency.
- Masking: data policies match on field name across every registered dataset and are global, with no escape even for an admin.
- Permissions: 6.2.5 split
UpdateTopicDetailsinto two actions, so custom roles granting the old one need re-granting by hand. - Portability: SQL Processors are proprietary, so anything built on them is a re-implementation if the team leaves.
Which should you pick?
Pick Kafdrop if:
- the tool is for engineers who already hold cluster credentials
- the value is looking at a message on a bad afternoon rather than delegated self-service
- the estate is one cluster
- the deployment already sits behind something that can authenticate for it
Pick Lenses if:
- people who are not Kafka engineers have to read a topic without writing consumer code
- SSO, SAML and role-based access have become a contract term
- one picture across producers, topics, connectors and consumers is the actual project
The question underneath both is what you are metering. Kafdrop takes its cost out of your engineers and leaves the access question to whatever sits in front of it. Lenses meters users, and then meters clusters again on the replication ladder. Anyone choosing between the two is really choosing whether the access model belongs inside the tool or in a proxy in front of it, and that decision is far harder to reverse than the purchase.
Kpow: role-based access with nothing extra to run
Kafdrop and Lenses both put the access decision somewhere other than inside a straightforward deployment. Kafdrop ships no authentication of its own, so keeping it safe means a proxy in front, and the feature request for a login was closed as not planned. Lenses puts access control inside the product, but only from DevX Team upward, and reaching that tier means standing up a central HQ node on PostgreSQL plus an Agent and an Agent database for every Kafka cluster. Kpow by Factor House keeps the access model role-based inside the product without either of those extra pieces: one stateless JVM container, no external database, reaching up to 12 clusters from a single instance. It is licensed per cluster at a published price, so the bill does not move when five engineers become fifty.
Neither Kafdrop nor Lenses prices the cluster itself, and neither settles access inside a plain deployment either. Role-based access with no proxy and no Postgres install is set out in full on Kpow’s product page, before Lenses’ step from Community to Team changes the bill instead.
Sources
- Apache Kafka 4.0 upgrade documentation
- Apache Kafka documentation on authorization and ACLs