Each main platform has a page of its own. This is not another.
A platform gets its own page when there is enough to say: a topology to browse, resources to operate on, an authorisation model to administer. Kafka, RabbitMQ, Redis and Apache Artemis (formerly ActiveMQ Artemis) each clear that. What is here does not — and saying so is more useful than padding two short sections into two thin pages.
The two halves below are not at the same stage in the same way, and the page does not average them. Kafka-protocol brokers work today and are covered by Community, with no module to add. Memcached also works today, and ships in Commercial.
If it speaks the Kafka protocol, it is already a connection.
BROKA's Kafka adapter opens a plain Apache AdminClient. There is no vendor branch, no capability table keyed by brand and no allow-list in the connection form — so a broker that implements the protocol is managed through the ordinary Kafka connection, with the same topics, consumer groups, produce and consume screens.
The claim is a protocol claim, and it is worth being precise about what that covers. Topics, partitions, consumer groups and offsets are the protocol, and they work. Kafka Connect and Schema Registry are separate services with their own endpoints — a broker that speaks the Kafka protocol does not automatically bring them, and where they are absent those screens say so rather than failing. The same goes for JMX: the broker health, request and JVM figures BROKA reads over JMX exist where the brokers expose a JMX agent BROKA can reach, and a managed service that exposes none reads Needs JMX in those places while everything else works.
Authentication is where the differences actually show. BROKA offers no authentication, SASL/PLAIN, SASL/SCRAM-SHA-256, SASL/SCRAM-SHA-512 and mutual TLS. Some managed services accept only a subset — Redpanda, for instance, accepts SCRAM and not PLAIN — so the method matters more than the brand. Cloud-specific IAM signing is not supported and is not offered in the form.
A cache, operated as a cache.
Memcached has no queues, no topics, no offsets, no delivery and no authorisation model. Treating it as another broker would leave most of a broker's navigation empty and imply guarantees it does not make. So it gets five screens that answer the questions a cache actually raises — and the first of them is why it is evicting.
Overview sums the nodes without pretending they are a cluster. Nodes is the only screen that acts on a server. Memory and slabs answers why a node reporting half its memory used is evicting constantly. Keys reads one at a time, with the metadata read that does not count as a hit, and lists a node's keys only when you ask. And Live events is a log, not a queue.
Memcached ships in Commercial. The five screens, what the console will not do, and the reasons it is not treated as a broker are on its own page.
What is not here, and why it is not promised.
Brokers that do not speak the Kafka protocol — Apache Pulsar and its neighbours — do not fall out of the existing adapter the way the first half of this page does. Supporting one is a module, not a connection string, and nothing on this page should imply otherwise.
They are worth considering and they are not committed. This page grows when something moves from the second sentence to the first, and not before.