AKHQ vs Lenses

Comparisons

Factor House·August 30, 2026·6 min read·Updated August 31, 2026

AKHQ vs Lenses, compared

F1 AKHQ and Lenses, side by side

AKHQ Lenses

Pricing unit Free, Apache 2.0, with no paid tier and no commercial support. Tiered by capability and user count. Team starts at 4,000 US dollars a year for up to 15 users.

Free tier The whole product. No feature is held back from the open release. Community is 5 users with Basic Auth only, so no SSO and no RBAC.

Adding an engineer No change to the bill. A step toward the 15-user Team ceiling, then custom pricing.

Adding a Kafka cluster One deployment already reaches it. Another Agent and another Agent database. Federated multi-Kafka sits in the custom-priced top tier.

External dependencies None. No database and no sidecar. PostgreSQL for HQ as the only supported storage option, plus a database per Agent.

Data masking Four modes, configured as global YAML with one filter per topic. It does not vary by who is looking. Global by field name across every dataset, applying to every user including an admin.

Audit trail Opt-in, written to a Kafka topic the operator nominates, with no audit view in the product. In-product audit logs carrying principal delegation, with listing granted to the Security Admin role.

Support GitHub issues. No SLA. A vendor under contract, with Team Support from the paid tier.

Both products as published in August 2026.

Key takeaway

AKHQ is free under Apache 2.0 with no paid tier, while Lenses Team starts at 4,000 US dollars a year for up to 15 users, so the first question is whether you are buying software or buying somebody to call. Lenses HQ requires PostgreSQL and each Agent needs a database of its own, reaching one cluster each, where AKHQ holds no state and reaches many clusters from one deployment. Both mask data, and neither varies it by who is looking. Kpow by Factor House is licensed per cluster at a published price.

What is AKHQ?

AKHQ is an open-source Kafka management UI under Apache 2.0, formerly KafkaHQ, self-hosted and built on Micronaut. One deployment reaches one cluster or many, covering topic browsing, live tailing, producing, consumer groups, Schema Registry, Kafka Connect, ACL management and role-based access with LDAP and OIDC.

Daily work: consumer group inspection, reading Kafka’s own consumer group protocol rather than owning it.
Configuration: connections, users, groups and registry links in YAML, deployed by Helm and reviewed like any other change.
Adoption: Michelin runs it across on-premise factory clusters and cloud deployments, and contributed resource-level authorisation back.
Releases: 0.28.0 in August 2026, after two earlier releases in the year.

What is Lenses?

Lenses is a commercial Kafka governance and data exploration platform that sits on top of clusters you already run. It operates as a Kafka client rather than a proxy, so nothing of it stands in the data path and no client configuration changes because it is there. The architecture is a central Lenses HQ node with a lightweight agent per cluster, and because that agent connects as an ordinary client, a KRaft cluster needs no broker-side modification to be reachable. Celonis acquired Lenses in early 2022, and 6.2.6 was released in August 2026. A data catalog groups topics by domain.

SQL Studio: a SQL interface for querying topics without writing consumer code, aimed at people who are not fluent in Kafka internals.
Topology and lineage: a view spanning producers, topics, connectors and consumers.
SQL Processors: Kubernetes-native stream processing jobs defined in SQL and built on Kafka Streams.

What is the official 2026 pricing of AKHQ and Lenses?

AKHQ costs nothing to license and its whole cost is operator time, so five people and fifty pay the same number. Lenses prices by capability and by user count. Community is free for up to 5 users with Basic Auth only, so no SSO and no RBAC. Team starts at 4,000 US dollars a year and reaches 15 users, adding SSO, SAML, RBAC and team support. Past the Team ceiling the only tier on the table is Multi-Kafka Enterprise, which is custom priced.

The dependency bill is the half no tier card shows. AKHQ holds no state and needs no database. Lenses HQ requires PostgreSQL, which is its only supported storage option, and each Agent needs a database of its own, with an embedded H2 alternative documented for evaluation only. One Agent connects to one Kafka cluster at a time, so a four-cluster estate is HQ, HQ’s Postgres, four agents and four agent databases. The product line also splits into DevX, the UI and governance surface, and K2K, which is replication. Exactly-once semantics, offset replication, autoscaling and schema migration sit on K2K Enterprise, from 1,000 US dollars per month with 5 clusters included and further clusters at 200 US dollars per month.

Where does each one run out?

AKHQ’s governance is present and shaped for a small team. Masking takes four modes, and the policy lives in application YAML keyed on topic and field path, so what is hidden is the same for everybody looking, with only one filter per topic supported.

Audit: opt-in, written to a Kafka topic the operator nominates, with no audit view inside the product.
Memory: a constant-increase report open since July 2022, and a second since May 2025.
Consumer groups: clusters carrying many of them need HIDE_EMPTY and skip-consumer-groups: true to keep startup responsive.
OIDC: the most active failure surface in the tracker, with new defects still arriving in August 2026.

Lenses runs out first at its own control plane. The current HQ deployment guide describes a single instance, with no replica count and no clustering guidance, so the node watching every cluster is the one thing without a second copy. Against Amazon MSK the default broker metrics refresh of roughly 5 seconds generates a high volume of JMX requests, and 30 seconds or higher is recommended.

Portability: SQL Processors are compiled and executed in Kubernetes and are specific to the product.
ACLs: the 6.2 line added filtering by operation and fixed creation and listing for principals carrying SPIFFE-format separators.
Permissions: 6.2.5 split UpdateTopicDetails into two actions, so custom roles granting the old one need re-granting by hand.

Which should you pick?

Pick AKHQ if:

the people using it are engineers who already hold cluster credentials
the estate is more than one cluster and one deployment should reach all of them
the cluster list and access model belong in source control as Helm YAML
there should be no database to back up or upgrade

Pick Lenses if:

the people who need the data are not Kafka engineers
SQL over topics is the capability being bought, rather than a tidier browser
stream processing jobs defined in SQL are part of the plan
a vendor under contract is required

Pick neither on the compliance story alone. AKHQ’s masking is global, so it cannot vary by who is looking. Lenses masks by field name across every dataset it knows about, and that policy is global too, applying to every user including an admin. What Lenses adds is built-in roles separating Admin, Operator and Security Admin. Underneath both, the access model the brokers enforce belongs to Kafka’s own authorizer, which both tools surface rather than own.

Kpow: adding a cluster doesn’t add a database

Adding a cluster costs something on both sides here. Lenses adds another Agent and another Agent database for it, and AKHQ takes that same cost out of your own engineers’ time instead, since one deployment already reaches it but somebody still has to watch it. Kpow by Factor House is licensed per cluster: a single stateless JVM container, configured through environment variables, with no external database, no sidecar and no persistent volume. One instance manages up to 12 clusters, so the fourth or the fortieth cluster is a config line, not another Agent and another database.

See what one container adds up to against an agent-per-cluster bill. Point Kpow at your own cluster and find out.

Sources

Apache Kafka documentation on consumer groups
Apache Kafka documentation on KRaft
Apache Kafka documentation on authorization