Best Kafka management tools for supermarkets and food distributors

Tools compared

Rank	Tool	Total (out of 110)	Out of the data path	On-prem and cloud together	Inspecting topic data	Many teams, shared clusters	Production access on request	Directory and Kafka sign-in	Cost a year (modelled)
1	Kpow	97	One container, state in your Kafka, not a proxy	Any distribution, 12 clusters per instance	kJQ search across topics, on the server	Tenants and per-action RBAC	Time-boxed temporary policies via API, staged approvals, masking per resource	SAML, OIDC, LDAP; Kerberos, SCRAM or mTLS to brokers	$20,880
2	Kafbat UI	78	One stateless container	Confluent Cloud broke in v1.4.x and v1.5.0	Message browsing	Per-resource roles per cluster	Per-resource RBAC, no approvals, masking for all viewers	OAuth2, OIDC, LDAP; no SAML	$11,520
3	AKHQ	76	One stateless container	Named connections	Topic data browsing	Groups by resource and cluster pattern	Regex groups, UI-only if JWT secret unset	LDAP, OIDC; no SAML	$16,320
4	Lenses	69	HQ on PostgreSQL, agent and database per cluster	Any Kafka API, agent per cluster	SQL over topics	Roles on groups only	Strict global masking, no approvals	SSO incl. Entra ID and Okta	$2,880 plus quoted licence
5	Confluent Control Center	43	Dedicated host, broker reporter JAR	Confluent Platform only	Topics > Messages view	Admin access only, per TD Bank	Confluent RBAC, no DENY, no approvals	OIDC on self-managed	$2,880 plus quoted subscription
6	Conduktor	68	Console on PostgreSQL; Gateway proxy in the data path	Confluent Cloud, Aiven, MSK, Cloudera	Browse and filter	Per user or group, most permissive grant wins	Per-viewer masking, cross-team access requests	LDAP, OIDC	$122,880; $212,880 with Gateway Core and Protect

No tool meets every column, and grocers and distributors commonly pair a management tool for people with broker ACLs or an authorizer for services.

The tools, ranked for supermarkets and food distributors

What supermarkets and food distributors need from a Kafka management tool

This page is about supermarket chains, grocers and food distributors, including foodservice distributors that supply restaurants: businesses that run Kafka under stores, warehouses, ordering and delivery rather than under payments or trading. For banks that run Kafka as shared infrastructure for many business lines, see best Kafka management tools for banks, and for Factor House’s overview of Kafka in retail, see Kafka for retail. Retail groups that sell through stores as well as online, with many squads on shared clusters, are covered in best Kafka management tools for retailers, and online-first businesses and marketplaces in best Kafka management tools for ecommerce companies and marketplaces.

In this industry Kafka tends to sit under the operation itself. At US Foods, which supplies about 250,000 restaurants and foodservice operators, Kafka is at the centre of MOXē, the ordering platform, moving data from databases, data lakes and object storage through the API customers order from, and its case study says a stalled topic or a bad offset puts the ordering experience for those customers at risk. The fullest public account of a grocer’s Kafka is Walmart’s: Factor House’s review of Walmart’s published Kafka architecture, which draws on the company’s own engineering posts and conference talks, describes a replenishment platform spanning more than 5,000 stores and 150 distribution centres that works through close to 100 million SKUs in under three hours, and Kai Waehner’s survey of Kafka in food and retail supply chains records the same pattern at Albertsons, Instacart and Migros. Work of this kind runs to a deadline, because a replenishment plan that arrives late means store orders that are placed late, so the time a platform team has to find and fix a stalled consumer is measured against the next order cut-off.

A grocer or food distributor may face less regulation than a bank, but the data in its topics, orders, stock, prices and customer accounts, is still the business, and it does not want a third party sitting in that stream. A management tool that runs inside the company’s own environment, connects as an ordinary Kafka client and needs no database of its own adds nothing between the ordering, stock and delivery services and the brokers, and nothing outside the company that can see the data. How a tool reaches the cluster also decides what it has to be sized for. A tool that connects as a client carries none of the application traffic, so the replenishment run and the holiday order peak never pass through it. A proxy does carry that traffic, and Kai Waehner’s Kafka Proxy Demystified sets out both sides of the trade: a proxy adds a network hop between clients and brokers and has to be deployed highly available and horizontally scalable, or it risks becoming a single point of failure, and in return it enforces policy on every application without code changes.

On this page that trade applies to Conduktor, whose Console connects to clusters directly and masks data in its own UI but needs an external PostgreSQL database, and Conduktor’s encryption, masking of the data itself, policy enforcement on client traffic and Virtual Cluster multi-tenancy all run through Conduktor Gateway, which Conduktor’s own documentation describes as a Kafka proxy between client applications and brokers. Kpow gives people RBAC, tenants, scheduled and staged changes, masking in inspection and an audit log without putting anything in front of the brokers, and the trade runs in both directions, because Gateway can enforce policy on applications and Kpow does not attempt that. Staying out of the data path is not unique to Kpow either: Kafbat UI and AKHQ are stateless containers that connect as clients and score the same 9 on this criterion, so the ranking between those three is decided by the other five criteria.

A supermarket chain adds stores, distribution centres and logistics, and its clusters rarely come from one vendor. Factor House’s retail page names Mercadona among the retail platform teams that use Kpow across Confluent, MSK and self-hosted clusters, and its announcement of its European expansion describes a supermarket chain that runs Confluent-managed Kafka beside self-managed open-source clusters carrying payments, warehouse movements and production data. Running two providers gives the platform team two of everything it looks at: Amazon MSK sends its Kafka metrics to CloudWatch and Confluent Cloud publishes its own through a separate Metrics API, so a question as simple as which cluster is running short of disk has two answers in two formats. The providers also differ underneath the shared protocol: Confluent Cloud does not support the Kafka admin call that normally returns disk usage, and Kpow’s Confluent Cloud guide has it read topic and broker disk figures from that Metrics API instead, which is the kind of per-provider work a tool has to do before one screen can show every cluster.

A tool that only manages one provider leaves the platform team with a console per vendor, and a provider’s own console leaves when the provider does. Gmarket, the South Korean marketplace that is part of Shinsegae Group, moved from the licensed Confluent distribution to community Kafka, lost Control Center in the move and had to replace the consumer lag and topic offset views its teams relied on. The console is also what its users have learned, about 150 of them at Gmarket and 130 at US Foods, so a tool that is independent of the Kafka vendor keeps a change of provider from also becoming a retraining exercise.

The people who need to look at Kafka are also unusually many. US Foods has about 130 developers across 12 product teams with access, 60 to 70 of them in the tool every day, plus QA teams in India and Argentina. Most of them need to read topics, inspect messages and follow consumer lag, and very few of them should be able to delete a topic or move a consumer group’s offsets. So the tool has to work for a crowd of readers, with a narrow set of people allowed to change production, and with offset changes that can run as part of a release instead of from a shell script.

What those readers are looking for is usually one record, and for a food distributor the search has a regulatory use as well. The FDA’s Food Traceability Rule requires businesses that manufacture, process, pack or hold foods on its Food Traceability List to keep key data elements for critical tracking events such as shipping and receiving, and to give the agency that information within 24 hours of a request, as an electronic sortable spreadsheet when the request comes during an outbreak or recall. The original compliance date was 20 January 2026, and the FDA has proposed extending it to 20 July 2028. Where shipping and receiving events move through Kafka, the first question in a recall, which shipments carried a given traceability lot code, is a search for that code across several topics. A topic is not the record the rule asks for, though: its records provision requires the records to be kept for two years, while a Kafka topic keeps messages for seven days unless its retention is changed, so inspection answers the question for what is still on the topic and the system of record answers it for the rest.

The other common search is for data that is well-formed and wrong. A talk by a Siemens data integration lead describes product master data arriving from several producers in a format that was agreed between teams and never validated, with values coming through as strings whatever their real type and one producer’s mistake reaching every consumer of the topic. Item, price and pack-size data reaches a grocer from many suppliers in much the same way, and a schema registry checks structure and not meaning, so the check that finds a wrong value is a person filtering the topic on that field.

Scoping that many people is a question of tenancy before it is one of permissions. Apache Kafka’s multi-tenancy guide describes sharing a cluster between teams through topic naming, security and quotas, and the alternative, a cluster for each team, multiplies the clusters a small platform team has to run. US Foods shows the shared model working, with 130 developers across 12 product teams able to inspect and troubleshoot and two solution architects holding delete access. The size of that crowd also decides what the tool costs. Grocery is a thin-margin business, and FMI’s annual survey put profit margins in the US grocery industry at 1.6% in 2023, so a price that rises with every developer, tester and operations user who needs to look gets attention. On this page’s model of 100 engineers on 4 clusters, pricing at $1,200 a seat comes to $120,000 a year and pricing at $4,500 a cluster to $18,000, and the comparison reverses for a team of fewer than 15, which pays less per seat. Claritev’s case study reports the buyer’s side of the same sum, with per-user licensing becoming the expensive option at about forty users.

Changes are far fewer than reads and carry more risk, and two of them catch grocers in particular. The first is adding partitions to a busy topic ahead of a seasonal peak, which is harder to undo than it looks. Walmart’s replenishment producers use a custom partitioner so that each item and store combination always lands on one partition, and Apache Kafka’s operations guide warns that after a partition increase messages with the same key may be routed to a different partition, that existing data is not redistributed and that the partition count cannot be reduced again. One of the four production incidents in the Factor House talk Things that go bump in the night is a partition increase that left messages unread, because producers wrote to the new partitions before the consumers had started reading them. The second is an offset reset that nobody intended, which a release can cause by renaming a consumer group: the renamed group has no committed offsets, and with auto.offset.reset set to earliest it starts from the beginning of the topic and processes every order still retained a second time. Both are reasons to hold topic and offset changes for a second person’s approval and to make each offset change an explicit, recorded action.

US Foods signs in its QA teams in India and Argentina through single sign-on, the same way as its developers, which gives the company one entry point for every time zone and one place to close it. Going through the identity provider also means the tool inherits the provider’s rules about where a sign-in may come from: Microsoft Entra’s Conditional Access network conditions, for example, can require multifactor authentication from outside the corporate network or block countries the organisation never operates from. A tool with local accounts sits outside those rules and has to be given its own.

Factor House’s retail page describes one such business without naming it: a European supermarket chain with more than 1,000 stores whose Kafka carries inventory, pricing and order pipelines. Its open-source Kafka UI could inspect only small volumes of messages and gave no view across clusters. After moving to Kpow, the chain inspected data at production scale, managed its clusters from one deployment and kept an audit trail of administrative operations across them, which the page says supports its GDPR and PCI DSS requirements.

What supermarkets and food distributors use Kpow for

Two businesses in food retail and distribution that run Kpow are named here: a foodservice distributor in the United States and a supermarket chain in Spain and Portugal. US Foods has described its use in a case study published by Factor House, and Factor House’s retail solutions page names Mercadona as a Kpow user, so both cards are tagged with the rubric criteria their evidence speaks to. What they have in common is many people working across several clusters, from a small platform team, and that is what the rubric below the rankings is built from.

How a supermarket chain or food distributor runs its Kafka with Kpow

Each workflow below uses documented Kpow features, linked to the Factor House docs, and the US Foods case study describes several of them in daily use.

Install it beside the clusters. Kpow runs as one Docker container or Java JAR, or on Kubernetes with the Helm charts, inside the company’s own network. It connects to the brokers as an ordinary Kafka client with the same cluster security settings as any other client, and it needs no external database: everything it needs to operate, snapshots, metrics and the audit log, is held in topics on the company’s own cluster, and its system requirements list no dependency beyond Kafka. Ordering, stock and delivery services keep talking to the brokers directly, and Kafka data stays in the company’s environment unless it connects one of Kpow’s optional AI features to a hosted model provider.

Put Confluent, MSK and self-managed clusters in one view. Multi-cluster configuration connects up to 12 clusters to one instance by repeating the connection settings with a numbered suffix, and each cluster brings its own Kafka Connect, schema registry and ksqlDB instances. Kpow has provider guides for Confluent Cloud, Amazon MSK and open-source Apache Kafka, so warehouse, store and ordering clusters sit in the same list and an engineer switches between them without another login. A Confluent Cloud cluster takes a Cloud API key as well as its Kafka credentials, because its disk figures come from the Confluent Cloud Metrics API. Each cluster also keeps its own registry, and Kpow’s schema registry configuration covers AWS Glue Schema Registry beside Confluent-compatible ones, which matters on MSK because Glue references a schema version by its UUID or version number and schema identities do not carry over from one registry to another. The documentation asks for Kpow to run close to the clusters it manages, so a business with clusters in several regions runs an instance in each.

Find an order or a delivery message. When an order does not arrive downstream, a developer or tester opens data inspect, selects the topics the message passes through, sets a time window, and filters by key, value or header with kJQ, for example on the order number. The search runs on the server, so nobody writes a throwaway consumer against production. The query engine draws records evenly from every partition of a topic, so a sample of an orders topic is not dominated by the partition that one busy store or item happens to hash to. When a consumer has stopped on a record it cannot read, data inspect can show only the records that fail to deserialise, with the schema ID and deserialiser for each message. The schema view shows what each payload should look like, and data produce writes a message to a topic, and US Foods’ teams republish or reproduce messages in Kpow when troubleshooting.

Give each product team its own view, and keep deletes to a few people. The platform team adds a tenant for each product team, scoped to its topics, consumer groups and connectors, and RBAC sets Allow, Deny or Stage per action and resource, with Deny winning where policies overlap. Most roles can read and inspect; delete actions stay with a small admin role, which is how US Foods keeps delete access to two solution architects while everyone else works within self-service plans.

Move consumer offsets as part of a release. In Kpow, consumer group offset actions reset a group by offset, timestamp or date and time, for the whole group or one topic or partition, and every one of them is scheduled: it runs once the group is empty, so a deployment can scale the consumers down, let the reset apply and bring them back, and Kpow tries for up to 15 minutes by default. US Foods runs these scheduled offset changes as part of production deployments, where it used to dig out a shell script. Setting a role to Stage on offset actions sends the request to an administrator for approval first, through staged mutations.

Keep connectors running. Many of the databases and other systems around a grocer’s Kafka reach it through Kafka Connect. Kpow’s Kafka Connect screens create connectors from a form, pause, restart or delete them, edit their configuration with sensitive values redacted, and restart a single failed task with its stack trace in view, across every Connect cluster configured for each Kafka cluster. Sink connectors can write the records they cannot process to a dead letter queue topic, and that topic repays reading in data inspect: in the Siemens talk on schema quality, 97.7% of the 400,000 error messages from one 16-hour run traced back to a single defect from one producer.

Sign in teams in other countries the same way. People sign in through the company’s identity provider with SAML, OpenID Connect or LDAP, and their groups map to roles, so a QA team in another country uses the same tool, with the same permissions model, as the developers at head office.

Watch lag before customers notice. Kpow publishes consumer group offsets and lag, with broker, topic and connector metrics, on Prometheus endpoints for Prometheus, Grafana or the company’s own monitoring, so the team that owns an ordering or stock consumer sees it falling behind before downstream systems do. Kpow also shows lag for empty consumer groups, which is the state a group is in after a poison message has taken its consumers down.

Keep a record of who changed what. The audit log records each action, data inspect queries included, with the user from the identity provider. Kpow shows the last seven days in the product and writes the record to the __oprtr_audit_log topic on the company’s own cluster, where Kpow’s topics default to one week of retention, so for a longer record webhooks send mutations, queries or both to Slack, Microsoft Teams or any endpoint the company chooses, such as its SIEM.

Kpow has limits a grocer should weigh before choosing it: it governs people working through Kpow, not services connecting to brokers, so broker ACLs or an authorizer remain the control for applications; Lenses’ SQL is a stronger query model than kJQ for analysts who think in SQL; one instance manages up to 12 clusters, so a larger fleet runs more than one instance; and the governance features on this page are Enterprise ones that Community Edition does not include.

To see these screens before installing anything, the live Kpow demo needs no signup and shows data inspect with kJQ, consumer groups and topic management on two MSK clusters. A quick check of this page’s rubric against the product is to switch between the two clusters, run a kJQ search across topics and open a consumer group to see its offset actions. The demo has no SSO configured, so sign-in is the thing to test in the company’s own environment. To run the workflows against the company’s own clusters, install Kpow from its container image or JAR; tenants, RBAC, staged mutations and the audit log are Kpow Enterprise features, and Community Edition is free for 3 clusters and 10 users.

Kpow live demo

Open Kpow the way a grocer's engineers would

The live Kpow demo needs no signup. Switch between two MSK clusters, search topic data with kJQ across several topics, and follow consumer groups, lag and their offset actions.

For platform teams running Kafka under stores, warehouses, ordering and delivery.

Try the Kpow demo→

FAQ

What is the best Kafka tool for a supermarket chain or food distributor?

On this page’s rubric, Kpow: it runs as one container with no external database and nothing in the data path, manages Confluent, MSK and self-managed clusters from one deployment, searches message content across topics with kJQ, scopes each product team with tenants and per-action RBAC, schedules offset changes, and signs people in through SAML, OpenID or LDAP. Kafbat UI is the strongest free option, but it has no tenants or approvals, and its Confluent Cloud connectivity broke in two recent releases. For a small team that only needs to browse, search and manage topics, Kpow Community Edition is free for 3 clusters and 10 users, without the governance features scored here.

How do grocers and food distributors use Kafka?

Kafka carries the operation: orders, inventory, pricing and deliveries. US Foods runs MOXē, the e-commerce platform its restaurant and foodservice customers order from, with Kafka at its centre, and Factor House’s retail page names Mercadona among the retail platform teams that use Kpow across Confluent, MSK and self-hosted clusters. That is why a management tool here has to reach several distributions and serve many readers.

Can one Kafka tool manage Confluent Cloud, Amazon MSK and self-managed clusters together?

Yes, if the tool is vendor-agnostic. Kpow manages self-managed Apache Kafka, Confluent Platform, Confluent Cloud and Amazon MSK from one deployment, up to 12 clusters per instance, each with its own Kafka Connect and schema registry. Confluent Control Center documents Confluent Platform clusters only. The general comparison is best tools to manage multiple Kafka clusters from one place.

What do teams move to when they outgrow AKHQ?

US Foods’ platform team started on hand-run CLI scripts, moved to AKHQ, and then to Kpow as Kafka spread to a dozen product teams and about 130 developers, according to its case study. AKHQ is free and browses topic data well, but its groups limit a role to resources whose names match a regex, with no tenant view of a team’s own resources, and it has no approval step or expiring grant. Kpow adds a tenant per team, staged approvals and scheduled offset changes, and signs people in through SAML, OIDC or LDAP. Kpow vs AKHQ compares the two in detail.

How does a grocer catch consumer lag before a promotion or holiday peak?

By watching lag per consumer group and partition and alerting on it before downstream systems fall behind. Kpow shows each consumer group’s lag in the UI and publishes group offset metrics on Prometheus endpoints for Grafana or the company’s own alerting. At US Foods, lag and offset issues that used to mean digging out a shell script are now resolved from a shared dashboard, according to its case study. Lag is usually a symptom of something else, and ByteByteGo’s write-up of Walmart’s Kafka platform reports consumer rebalancing as one of the most frequent problems its engineers met, set off when consumer pods join or leave a group or when the broker judges a consumer to be stuck, so a group’s state and membership are worth watching beside its lag in the weeks before a peak. Best tools to monitor Kafka consumer lag compares the options.

How do you reset Kafka consumer offsets safely during a deployment?

Stop the consumers, reset the offsets while the group is empty, then start them again, and keep a record. In Kpow, offset resets are scheduled mutations: they wait until the group is empty, apply by offset, timestamp or date, and can be held for an administrator’s approval with staged mutations. Best tools to reset Kafka consumer group offsets compares the options.

Can a Kafka management tool help trace a food recall?

It can answer the first question quickly for data that is still on the topics. The FDA’s Food Traceability Rule requires covered businesses to give the agency traceability information within 24 hours of a request. A tool that searches by key, value or header across several topics finds the shipping and receiving events that carry a traceability lot code without anyone writing a consumer. Kafka topics keep messages for seven days by default and the rule requires records to be kept for two years, so the traceability record itself has to live in a system built to keep it.

Does a grocer need a Kafka proxy to control access?

No. Controlling what people can see and do in a tool, with RBAC, tenants, masking in inspection and an audit log, works from a tool that connects as an ordinary Kafka client. A proxy is only needed to enforce policy on application traffic, and it puts a vendor’s component in the path of every order and stock update.

Does a supermarket chain need an audit trail of who changed its Kafka?

Factor House’s retail page describes a European supermarket chain with more than 1,000 stores whose audit trail of cluster operations supports its GDPR and PCI DSS requirements. Kpow’s audit log records each action, data inspect queries included, with the user from the identity provider; it shows the last seven days in the product, and webhooks send the record to a SIEM for a longer history. The audit trail is not one of this page’s six weighted criteria; best Kafka management tools for banks weights it twice.

How these tools were scored

Six criteria, drawn from the US Foods case study, Factor House’s retail page and what it means to put a third party in the stream of orders and stock, score every option from 0 to 10. They are listed here in order of weight; the weights add up to 11, so the total is out of 110.

1. Out of the data path. A management tool that runs in the company’s own environment, connects as an ordinary Kafka client and keeps no data outside its clusters adds nothing between ordering, stock and delivery services and the brokers, and puts no third party in the stream. Scored lower: tools that need an external database, 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 or a component on the brokers 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. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.

2. On-prem and cloud together. Supermarket and distribution platforms rarely run one distribution; Factor House’s retail page names Mercadona among the retail platform teams that use Kpow across Confluent, MSK and self-hosted clusters, and describes a European supermarket chain with more than 1,000 stores that had no view across its clusters before Kpow. One deployment of the tool should reach all of them, with their Connect clusters and schema registries. Best tools to manage multiple Kafka clusters from one place compares this in detail.

3. Inspecting topic data. Most of the people using the tool are reading: finding an order or delivery message by key, value or header across several topics, on the server, without writing a consumer against production. SQL over topics scores highest, filtered search across topics next, and browsing or filtering one topic at a time a point lower. Best tools to search messages across Kafka topics covers search in detail.

4. Many teams, shared clusters. US Foods has about 130 developers across 12 product teams on its clusters, so each team needs to be scoped to its own topics, consumer groups and connectors, and the platform team should onboard a team with a policy rather than a cluster.

5. Production access on request. Who can change production, and how? US Foods keeps delete access to two solution architects and runs offset changes as scheduled mutations during deployments. The criterion asks whether destructive actions can be limited by role and held for a second person’s approval, whether read access to production can be granted for a task and expire, and whether sensitive fields can be masked. The wider set of controls over deletes and offset resets is compared in best tools to control destructive Kafka operations.

6. Directory and Kafka sign-in. People should sign in through the company’s identity provider, whether that is SAML, OIDC or LDAP, with groups mapped to roles, so that QA and support teams in other countries use the same tool the same way. On the cluster side the tool has to connect the way the clusters already authenticate clients. Best tools for Kafka SSO integration covers the protocol detail.

A per-person audit trail is not one of the six weighted criteria here, because the six slots go to the mixed-cluster and inspection needs that set grocers and distributors apart; Kpow’s audit log is covered in the workflows above, and best Kafka management tools for banks weights it twice. The cost figures model a grocer or distributor running 4 clusters (development, test, pre-production and production) for 100 engineers at $120 an engineer-hour, and each card prints its own assumptions. The general listicle view, without this weighting, is in best Kafka management tools.

F1 What a grocer or food distributor runs into, and what the Kafka tool has to do about it

What happens at a grocer or distributor What the Kafka tool has to do

Nobody else in the data Orders, stock, deliveries and customer accounts move through Kafka, and the business does not want a third party sitting in that stream Run inside the company's own environment as a Kafka client, with no vendor proxy and no external database

Mixed clusters E-commerce, point-of-sale, supply chain and analytics clusters run on Confluent, Amazon MSK and self-managed Kafka at the same time Manage every cluster, with its Kafka Connect and schema registry, from one deployment

Many people looking Developers, QA testers and operations staff need to see what is flowing in production Search topic data by key, value or header on the server, without writing a consumer

Many teams, few admins A dozen product teams share clusters, and only a handful of architects should be able to delete anything Scope each team to its own resources, and keep destructive actions to a few roles

Offset changes in a release A deployment needs a consumer group moved to a new offset, which used to mean digging out a shell script Schedule the offset change in the tool, and hold it for approval where the role requires it

Teams across time zones QA and support teams in other countries sign in to the same clusters Sign people in through the company's identity provider, with groups mapped to roles

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, On-prem and cloud together counts twice, Inspecting topic data counts twice, Many teams, shared clusters counts twice, Production access on request counts once and Directory and Kafka sign-in counts once, for a total out of 110. Out of the data path counts three times because a grocer or food distributor may face less regulation than a bank, but it still does not want a third party sitting in the stream of its orders, stock and customer accounts, and a tool that keeps state in a database of its own is one more system to run. Mixed clusters count twice because supermarket and distribution platforms run Confluent, Amazon MSK and self-managed Kafka side by side. Inspecting topic data and many teams on shared clusters count twice, because the people using the tool are many developers, testers and operations staff, not a few administrators. Production access and directory sign-in 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 97 out of 110. The other options follow by total. Conduktor is listed last whatever its total; on its total of 68 it would place fifth.

Related reading

• Kafka: the complete guide
• How US Foods scaled Kafka access to 130 developers
• Best tools to manage multiple Kafka clusters from one place
• Best tools to reset Kafka consumer group offsets
• Best tools to search messages across Kafka topics
• Best Kafka management tools for banks
• Best Kafka management tools for retailers
• Best Kafka management tools for ecommerce companies and marketplaces