Best Kafka management tools for airlines and travel companies

Tools compared

Rank	Tool	Total (out of 100)	Out of the data path	Many teams, shared clusters	Audit trail per person	On-prem and cloud together	Who can see unmasked data	Inspecting topic data	Cost a year (modelled)
1	Kpow	86	One container, state in your Kafka, not a proxy	Tenants and per-action RBAC	Every action with the IdP user, data queries included	Any distribution, 12 clusters per instance	Server-side, show last four, no per-role exemption	kJQ search across topics, streaming search	$20,880
2	Kafbat UI	69	One stateless container	Per-resource roles per cluster	Optional, reads at level ALL, no view	Confluent Cloud broke in v1.4.x and v1.5.0	Server-side, the same for every viewer	Browse and inspect messages	$11,520
3	AKHQ	64	One stateless container	Groups by resource and cluster pattern	Opt-in, no reads, no view	Named connections	Global filters, the same for every viewer	Browse topic data	$16,320
4	Lenses	61	HQ on PostgreSQL, agent and database per cluster	Roles on groups only	In-product audit log from Team tier	Any Kafka API, agent per cluster	Strictest, no exemption even for admins	SQL over topics	$2,880 plus quoted licence
5	Confluent Control Center	38	Dedicated host, broker reporter JAR	Admin access only, per TD	Broker principal, not always the person	Confluent Platform only	No masking described	Messages view, Avro key bug	$2,880 plus quoted subscription
6	Conduktor	62	Console on PostgreSQL; Gateway proxy in the data path	Per user or group, most permissive grant wins	70+ event types with user, in the UI	Confluent Cloud, Aiven, MSK, Cloudera	Console exemptions per user or group	Browse and filter topic data	$122,880; $212,880 with Gateway Core and Protect

No tool meets every column, and airlines commonly pair a management tool for people with broker ACLs or IAM policies for services.

The tools, ranked for airlines and travel companies

What airlines and travel companies need from a Kafka management tool

This page ranks tools against what airlines, airports, booking platforms and other travel companies need from Kafka tooling, as far as those needs can be read from what the companies and their vendors have published. Factor House names no airline or travel company as a Kpow customer, so the ranking rests on the industry’s requirements and on documented product behaviour, and it carries no customer evidence from this industry for Kpow. A travel company that mostly sells online and runs Kafka with a small platform team is closer to best Kafka management tools for ecommerce companies and marketplaces, and one whose main concern is many squads on shared clusters to best Kafka management tools for retailers. Where card data is the centre of the business, see best Kafka management tools for payments companies. For a bank’s version of the shared-cluster problem, under a regulator, see best Kafka management tools for banks, and for the regulation-by-regulation view, best Kafka governance tools for financial services.

Kafka sits in the operational core of this industry. Kai Waehner’s survey of Apache Kafka in the airline, aviation and travel industry describes airlines, airports and global distribution systems that have to work together “24/7” and in real time, and his account of how Lufthansa uses Apache Kafka for middleware and analytics describes KUSCO, the airline’s integration platform on Confluent, taking over work that traditional message queues such as TIBCO EMS and IBM MQ used to do. Virgin Australia rebuilt its Flight State Engine, which holds the authoritative view of flight status and streams updates to internal and external systems, on Kafka in 2022, as told in Virgin Australia’s journey with Apache Kafka. When flight status and bookings travel over Kafka at every hour, anything placed between the applications and the brokers becomes part of flight operations, which is why this page weights staying out of the data path highest.

The clusters are shared by many teams, and not all of the people who need access are Kafka engineers. Waehner writes that more projects keep joining KUSCO at Lufthansa and that Virgin Australia’s platform became the base for other business units. Conduktor’s customer stories give the numbers for its own customers: more than 2,000 self-service users at a European airline it does not name, more than 50 teams and 2,300 topics at Flix, and at Virgin Australia testers and analysts working beside developers. A management tool for this industry has to scope each team to its own topics and consumer groups, and let a tester check that a booking event arrived without a ticket to the platform team.

The clusters also sit in more than one place. The European airline in Conduktor’s story ran 25 Kafka clusters across three data centres before it moved them to Confluent Cloud over nine months, Schiphol Group, which runs Amsterdam’s airport, moved from open-source Kafka to Confluent Cloud and runs different clusters for different uptime, security and latency needs, according to Waehner’s write-up of airports and airlines using Kafka and Flink, and Agoda describes events streaming across multiple data centres on the Apache Kafka project’s Powered By page. During a migration both sides are live, so one deployment of the tool has to reach clusters in the company’s own data centres and in the cloud.

Booking and loyalty topics carry personal data: passenger names, contact details, travel plans and, where card data reaches the company’s own systems at all, card details. Conduktor’s Flix story speaks of “the sensitive nature of payment transactions and personal information required for travel bookings”. Article 25 of the GDPR asks for measures that ensure, by default, that personal data is not made accessible to an indefinite number of people without the individual’s intervention, so a tool that shows booking topics to developers, testers and analysts should mask those fields for the people who do not need them and record who looked. PCI DSS is written for any business that stores, processes or transmits cardholder data, or could affect the security of the environment that holds it, and the PCI Security Standards Council’s glossary defines masking as concealing a segment of the card number when it is displayed. An airline that keeps card numbers out of Kafka with a payment provider or tokens has less to mask, and one that does not needs the tool to mask them.

Each of the six criteria this page scores comes from one of those needs, and each has a detail that general lists of Kafka tools leave out.

Out of the data path. A management tool reaches a cluster either as an ordinary Kafka client beside the applications or as a proxy that producers and consumers connect through. Conduktor Console connects to clusters directly and masks data in its own UI, but it needs an external PostgreSQL database, and Conduktor’s field encryption, masking of the data itself, policy enforcement on client traffic and Virtual Cluster multi-tenancy run through Conduktor Gateway, which Conduktor’s own documentation describes as a Kafka proxy between client applications and brokers. For an airline that proxy has a real use, because the European airline in Conduktor’s customer story needed end-to-end encryption before its data could reach Confluent Cloud, and a client-side tool such as Kpow does not attempt that. That has a cost in card scope. The PCI Security Standards Council’s guidance on PCI DSS scoping and segmentation applies the standard to every system component included in or connected to the cardholder data environment, which it defines as the people, processes and technologies that store, process or transmit cardholder data. A proxy that booking and payment services produce through transmits every card message that passes it, so it sits inside that environment at full booking volume and at every hour of the day. A console that connects as a client is in scope too wherever it can read card topics, but it handles card data only when a person displays a topic, and masking keeps the full card number out of what it shows. Approval time also counts in a large group: Belong, an Australian telecommunications brand, chose a Kafka service that was already approved because approving a new vendor would have taken too long, as its engineers describe in the talk Implementing Kafka at Belong, and in an airline group a tool with no database and nothing on the path is a shorter security and vendor review than one with both.

Many teams, shared clusters. Shared clusters grow by onboarding. Waehner’s Lufthansa write-up describes more and more projects being onboarded onto KUSCO, and the European airline in Conduktor’s story reports more than 2,000 self-service users. At that size the limit is the central platform team and not the cluster, because a team that grants every topic read and every offset reset by hand stops keeping up after a few dozen tenant teams. TD’s platform team describes exactly that in its talk on running Kafka at bank scale: it created every artefact by hand and burned out before it built self-service. Self-service still has an edge that should stay central, which is who may connect to the cluster. The reference roles in Factor House’s London workshop deny even topic owners the right to change ACLs or broker configuration, the separation of duties that control AC-5 of NIST SP 800-53 describes, so a loyalty team can manage its own topics and consumer groups while access for applications stays with the platform team.

Audit trail per person. A console without an audit log leaves no record of who reset a consumer group’s offsets on a check-in topic, changed a topic’s configuration or produced a test message into production, however good its screens are. Where booking topics carry card data, reads have to be in the record as well: PCI DSS Requirement 10 is titled “Log and monitor all access to system components and cardholder data”, and Microsoft’s mapping of Entra ID to PCI DSS Requirement 10 lists the sub-requirement that audit logs capture all individual user access to cardholder data. The brokers see the tool’s own service account and not the engineer, so only the tool’s log can name the person who searched a booking topic.

On-prem and cloud together. A move from data centres to the cloud, like the European airline’s 25 clusters and 170 applications, is carried out topic by topic, and the risk sits in the clients. Before a topic moves, every producer and consumer of it has to be found, because a producer or consumer that nobody found is the one that fails after the move, and low-tier topics are the place to rehearse, as the webinar Reduce Kafka spend and operational risk explains. The replication itself has to land each consumer group in the right place: Apache Kafka’s geo-replication documentation lists cloud migration among the uses of MirrorMaker 2 and publishes a checkpoint latency metric for how long consumer offsets take to replicate, and Insight’s write-up of MirrorMaker 2 production traps states the requirement plainly, that consumer groups must resume at the exact right position on the target. A tool that shows each topic’s consumer groups and lag on the old and new clusters in one view is how a team finds the stragglers and confirms that each group has moved. The tool’s own position matters as well. Factor House neither sells Kafka nor modifies or extends it, holding its tools to the open-source Apache projects as they are, as discussed on the podcast Behind the Stream, so Kpow has no stake in whether an airline ends up on Confluent Cloud, Amazon MSK or its own data centres.

Who can see unmasked data. Passenger data in an airline’s topics is not only names and card numbers. The Canada Border Services Agency’s page on Advance Passenger Information lists what airlines are required by law to send before a flight arrives: name, date of birth, gender, citizenship and travel document data such as the passport number, read from the passport’s machine-readable zone, with more collected at check-in. Check-in and departure control events therefore carry identity documents, and permission to read a topic and permission to see a passport number in the clear are separate decisions. An engineer tracing why a passenger’s boarding message stalled needs the event’s structure and status, not the passport number, so masking those fields on the server keeps production debugging from turning into access to identity documents. Kpow masks per topic and not per viewer, which is why Conduktor Console, whose policies can exempt the owning team, scores higher on this criterion.

Inspecting topic data. Without a way to look inside topics, teams build services just to confirm that a message arrived. Pickles, which runs online auction platforms, describes in its case study how checking topics by hand could take hours and how it could not keep building a custom microservice for every use case. At an airline the person checking is often a tester or analyst confirming that a booking event reached the loyalty or flyer-profile topic, the people Virgin Australia names beside developers in its Conduktor customer story. Inspection runs the other way in development too: consuming teams produce sample messages from the console when the producing side is not ready, as TD’s platform team describes in its talk, rather than writing a throwaway producer, which Kpow does with data produce under the same RBAC and audit log as every other action.

What airlines and travel companies use Kafka for

No airline or travel company has published an account of running Kpow, so this section has no customer cards. It lists what companies in the industry have said in public about their Kafka, which is the evidence the rubric on this page is built from. None of the companies below is presented as a Factor House customer.

Flight operations. Virgin Australia’s Flight State Engine streams flight status to internal and external systems, and it replaced an Oracle SOA system whose monitoring was limited, as Waehner’s summary of the project describes. Lufthansa uses its Kafka platform for anomaly detection with ksqlDB and for real-time predictions in fleet management.

Bookings and loyalty. Virgin Australia’s Business Rewards programme moves events between Salesforce, Amadeus and iFly over Kafka topics, where it previously relied on manual workflows, and Conduktor’s Virgin Australia story adds that the airline ingests booking information from third-party travel sites to update flyer profiles. Amadeus, which runs one of the largest global distribution systems, says on the Apache Kafka Powered By page that Kafka is the event log for its microservice-based streaming applications.

Maintenance and legacy integration. Singapore Airlines presented a predictive maintenance pipeline built on Kafka Connect, Kafka Streams and KSQL in 2018, and Air France Hop used change data capture into Kafka to connect newer services to older monolithic systems, both covered in Waehner’s survey.

Airports. Schiphol Group uses Kafka as its core integration platform, on Confluent Cloud, with separate clusters for workloads with different uptime, security and latency needs.

Online travel and ground transport. Agoda reports trillions of events a day through Kafka across multiple data centres, and Trivago and Hotels.com are listed on the same Powered By page for stream processing and event collection. Flix, which runs coach and rail services, describes Kafka use across 10 domains and more than 50 teams, covering fleet tracking, routes and payments.

Which management tool these companies use is public for only a few of them, and those are Conduktor customers: Virgin Australia, Flix and the unnamed European airline appear in Conduktor’s own customer stories. That is a point in Conduktor’s favour which the scores do not capture, because the rubric scores what each tool does and not who has bought it.

How airlines and travel companies would run their Kafka with Kpow

The workflows below are how an airline or travel platform team would put Kpow to work on shared clusters. Each one is built from documented Kpow features; none is taken from an airline’s own account.

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 or cloud account. It needs no external database, because its state lives in topics on the company’s own clusters, and it connects as an ordinary Kafka client with the same cluster security settings as any other client, so flight and booking events keep travelling from applications to brokers directly, and the Kpow product page describes it as running with no data leaving the company’s environment.

Reach the data centre and the cloud from one place. One instance manages up to 12 clusters, whether they are self-managed Apache Kafka, Confluent Platform, Confluent Cloud or Amazon MSK, so the clusters an airline is moving from and the ones it is moving to sit in the same view during a migration. A fleet larger than 12 clusters, such as the 25 in the European airline’s story, would run more than one instance.

Give each team its own view. A tenant includes or excludes topics, consumer groups and whole Connect clusters or schema registries by name, prefix or suffix, so a team whose topics start with loyalty- sees only those, plus the topics its consumer groups read, as if they were the only resources on the cluster. Tenants and RBAC are defined in a YAML file, which fits a GitOps review, and RBAC sets Allow, Deny or Stage per action and resource, with Deny winning where policies overlap.

Sign in developers, testers and analysts through the company directory. Kpow takes SAML from Okta or Microsoft Entra ID, any OpenID Connect provider, or LDAP, and maps directory groups to roles and tenants, so nobody needs a Kafka credential of their own to look at a topic.

Find one booking across topics. When a booking, a loyalty update or a flight event looks wrong, an engineer uses Data Inspect with a kJQ filter to search for one booking reference or flight number across several topics at once, on the server, by key, value or header. Data policies redact passenger names, contact details and card fields in the results, down to the last four digits of a card number, so the engineer sees the event history without the passenger’s details.

Follow lag when operations are disrupted. Weather, strikes and schedule changes send bursts of events through flight, crew and notification pipelines. Kpow shows each consumer group’s lag by topic and partition, and publishes it with broker, topic and connector metrics on Prometheus endpoints for Grafana, AlertManager or the company’s own monitoring. When a consumer has to skip or replay messages, the group actions reset, clear or skip offsets for a whole group, a host, a topic or a single partition, scheduled to run once the group is stopped. Scaling out is the usual answer to a backlog, and it has a cost under Kafka’s classic consumer protocol, which KIP-848 describes as relying on a group-wide synchronization barrier: the whole group rebalances whenever a consumer joins, leaves or fails, and a rebalance costs more as the group grows. Adding consumers in the middle of a disruption can therefore pause the group while it rebalances, so lag rises before it falls, and the new protocol from that KIP, generally available since Kafka 4.0 for consumers that opt into it, removes the barrier.

Hold risky changes for a second person. With staged mutations, a role can be set to Stage on actions such as deleting a topic or resetting offsets in production, so the request waits in Kpow until an administrator approves or denies it. Where an engineer needs extra rights for one incident, an admin, or a ticketing system calling the Kpow API, creates a temporary policy that expires on its own.

Restart a failed connector. Kpow manages Kafka Connect clusters beside the Kafka clusters they serve, so the team that owns a connector loading events from a reservation system or a loyalty database can see its tasks, read the error and restart it from the same UI, within its tenant.

Keep a record of who did what. The audit log records each action, data inspect queries included, with the user from the directory and the policy that allowed it. 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 the company’s SIEM.

Govern Flink jobs the same way. Airports and travel companies that run Apache Flink beside Kafka, as Schiphol Group does and as Booking.com does for its security platform, can put the same directory sign-in and Allow, Deny or Stage policies over their Flink jobs with Flex.

To see these screens before installing anything, the live Kpow demo needs no signup and shows data inspect, consumer groups, topic management and the audit trail in the __oprtr_audit_log topic on MSK Secondary. The demo has no SSO, tenants or data policies configured, so sign-in, per-team views and masking are the things 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, temporary policies, staged mutations, masking 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 an airline's engineers would

The live Kpow demo needs no signup. It runs on two Amazon MSK clusters: search topics for one key, follow a consumer group's lag, then read the audit trail on the __oprtr_audit_log topic of the MSK Secondary cluster.

For platform teams running Kafka for flight operations, bookings and loyalty on shared clusters.

Try the Kpow demo→

FAQ

What is the best Kafka UI for an airline?

On this page’s rubric, Kpow: it runs as one container with no external database and nothing in the data path, scopes each team to its own topics, groups and connectors with tenants, records every action and data query with the person, manages self-managed, Confluent and MSK clusters from one deployment, masks passenger and card fields in inspection, and searches several topics at once on the server. Kafbat UI is the strongest free option for a single team that signs in with OIDC. Conduktor is the tool with published airline customers, and it scores highest on who can see unmasked data.

Which Kafka management tools do airlines use today?

Few airlines say which management tool they use. Conduktor publishes customer stories for Virgin Australia and for a European airline it does not name, and shows the Lufthansa and Air France logos on its home page. Lufthansa’s Kafka platform runs on Confluent, whose console for self-managed clusters is Control Center. Factor House names no airline as a Kpow customer, so this page ranks tools on what they do against the industry’s requirements, and it should be read as that and not as a record of who uses what.

Does a Kafka management tool need to be a proxy to govern access?

No. Governing what people can see and do in a tool, with tenants, RBAC, masking in inspection and an audit log, works from a tool that connects as an ordinary Kafka client. A proxy is needed to enforce policy on application traffic or to encrypt records before they reach the brokers, and it puts a component in front of every producer and consumer that sends or reads a flight or booking event.

Does PCI DSS apply to an airline’s Kafka tooling?

It applies to a business that stores, processes or transmits cardholder data, and to anything that could affect the security of the environment where that data lives. If card numbers never reach the airline’s own Kafka topics, because payment runs through a provider or tokens, the Kafka tooling is not handling card data. If they do, a management tool that can display those topics handles card data too, so it should mask the card number for anyone without a business need to see it and record who looked, while a proxy that producers and consumers connect through carries every card message in transit. Best Kafka management tools for payments companies covers the PCI DSS detail.

How do you manage Kafka during a migration from a data centre to the cloud?

Use one tool that reaches both sides, because for the length of the migration the old clusters and the new ones are both live. Kpow manages self-managed Apache Kafka, Confluent Platform, Confluent Cloud and Amazon MSK from one instance, up to 12 clusters, so consumer lag, topics and access policies for both sides are in one place. Kpow does not move or encrypt the data itself; replication between clusters is the job of tools such as MirrorMaker 2 or Confluent’s Cluster Linking. Best tools to manage multiple Kafka clusters from one place compares the options.

Is a free Kafka UI enough for a travel company?

For a small team browsing topics and consumer groups, often yes. Kafbat UI and AKHQ are free and run as one container each, and Kpow Community Edition is free for up to 3 clusters and 10 users, with topic search and inspection, consumer group and offset management, schema registry and Kafka Connect. None of the free options gives each team its own view of a shared cluster or an audit trail that can be read in the product; in Kpow those are Enterprise features.

How these tools were scored

Six criteria, each taken from published accounts of how airlines and travel companies run Kafka or from what GDPR and PCI DSS ask of a tool that shows passenger and card data, score every option from 0 to 10. They are listed here in order of weight; the weights add up to 10, so the total is out of 100.

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 the company’s clusters adds nothing between flight, booking and loyalty services and the brokers, and gives the shortest answer when the security team asks which third parties can see passenger data. 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. Many teams, shared clusters. Flight operations, bookings, loyalty, maintenance and data teams on a handful of clusters need each team scoped to its own topics, consumer groups and connectors, so the platform team can onboard a team with a policy and not a cluster, and a team sees only what it owns. This criterion uses the same scores as the banking page; best tools for Kafka role-based access control (RBAC) compares the permission models in more detail.

3. Audit trail per person. When people work through a shared tool, the broker only sees the tool’s own service account, so only the tool’s log can name the person. An airline needs that log to include data reads as well as changes, so it can show who looked at a booking topic as well as who changed its configuration, and to be readable without building a consumer first. Best tools for Kafka audit logging compares the layers in detail. Scores are the same as on the banking page.

4. On-prem and cloud together. Airlines and airports in the published accounts above run Kafka in their own data centres, on Confluent Cloud, or on both while they migrate. One deployment of the tool should reach all of them; the general comparison is best tools to manage multiple Kafka clusters from one place. Scores are the same as on the banking page.

5. Who can see unmasked data. This criterion asks what people see once they are in a topic. It scores who can see the real passenger or card value through the tool, whether masking can be bypassed, and whether the team that owns the data can be exempted while everyone else sees it masked. The scores are the same as on best tools for Kafka data masking, which compares masking in more depth, and Control Center, which that page does not score, gets 2 because no masking is described for it. Conduktor scores highest here and Kpow does not.

6. Inspecting topic data. Tracing a booking, a loyalty update or a flight event means finding specific messages 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. Scores are the same as on the insurers page, and best tools to search messages across Kafka topics covers search in detail.

Production access on request and directory sign-in are not scored separately on this page; the banking page scores both, and Kpow leads on each there. Encrypting records before they reach the brokers is not scored either, because it is the work of a proxy or of the applications themselves and not of a management tool; of the tools here only Conduktor offers it, through Gateway. Who has bought each tool is also left out of the scores, which is why Conduktor’s airline customers appear in its card and not in its total.

The cost figures model an airline or travel company running 4 clusters (development, test, and production clusters for flight operations and for bookings and loyalty) for 100 engineers, testers and analysts 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 for 2026.

F1 What an airline or travel company runs into, and what the Kafka tool has to do about it

What happens at an airline or travel company What the Kafka tool has to do

Flight status at every hour Flight status, schedule changes and bookings stream to internal and partner systems around the clock Run inside the company's own environment as a Kafka client, not in front of the brokers as a proxy

Many teams Flight operations, bookings, loyalty, maintenance and data teams share a few clusters Scope each team to its own topics, consumer groups and connectors, by name or prefix

Passenger and card data Booking topics carry names, contact details, travel plans and, in places, card details Record who looked at which topic, with the person's own identity, and keep the record readable

Data centres and cloud Clusters in the company's own data centres run beside managed Kafka during and after a migration Manage every cluster from one deployment, whatever the distribution

Who sees the real value Developers, testers and analysts all open booking and loyalty topics Mask passenger and card fields for the people who do not need them

Finding one booking A booking, a loyalty update or a flight event looks wrong and nobody knows which service changed it Search topics by key, value or header on the server, without writing a consumer

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, Many teams, shared clusters counts twice, Audit trail per person counts twice, On-prem and cloud together counts once, Who can see unmasked data counts once and Inspecting topic data counts once, for a total out of 100. Out of the data path counts three times because an airline's Kafka carries flight status, schedule changes and bookings at every hour of the day, and a tool that sits between the applications and the brokers puts a vendor's proxy on the path those events take, and inside PCI DSS scope wherever card data passes through it, while a tool with a database of its own is one more system to patch and keep available. Many teams on shared clusters and the per-person audit trail count twice: published accounts describe dozens of teams and, at one European airline, more than 2,000 people working on the same Kafka platform, and booking topics carry passenger and card data, so the company has to be able to show who looked at them. Running clusters in the company's own data centres and in the cloud together, who can see unmasked data, and inspecting topic data count once each. 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 86 out of 100. The other options follow by total. Conduktor is listed last whatever its total; on its total of 62 it would place fourth.

Related reading

• Kafka: the complete guide
• Best Kafka management tools for banks
• Best Kafka management tools for payments companies
• Best Kafka management tools for ecommerce companies and marketplaces
• Best Kafka management tools for retailers
• Best Kafka governance tools for financial services
• Best tools to manage multiple Kafka clusters from one place
• Best tools for Kafka data masking
• How Booking.com uses Apache Flink in production