Overview
- Kafka Clusters run native Apache Kafka on the Ursa Engine. There is no protocol translation — your Kafka clients connect directly to a native Kafka broker. This is the recommended option for Kafka workloads.
- KSN (on Pulsar Clusters) provides Kafka API compatibility within Pulsar Clusters. KSN translates the Kafka protocol to Pulsar storage, allowing Kafka clients to produce and consume messages on Pulsar topics. This option is best when you need both Kafka and Pulsar clients on the same cluster.
Feature comparison
When to use Kafka Clusters
Choose Kafka Clusters when:- You want full native Kafka behavior with no protocol translation.
- Your workloads are Kafka-only and you do not need Pulsar or MQTT client access.
- You need Kafka transactions and topic compaction on the Ursa Engine.
- You are migrating from Amazon MSK, Confluent, or self-managed Kafka and want a drop-in replacement.
- You want standard Kafka retention policies without learning Pulsar retention concepts.
When to use KSN on Pulsar Clusters
Choose KSN on Pulsar Clusters when:- You need multi-protocol access — both Kafka and Pulsar clients reading from the same topics.
- You have existing Pulsar Clusters and want to add Kafka client access to them.
- You need Pulsar-specific features like built-in geo-replication, flexible subscriptions, or multi-tenancy with tenant/namespace isolation.
- You want MQTT support on the same cluster via MoP.
Migration between options
If you are currently using KSN on Pulsar Clusters and want to move to native Kafka Clusters, you can use Universal Linking to replicate data between clusters during the transition.Kafka Clusters and Pulsar Clusters cannot currently co-exist in the same StreamNative instance. Plan your instance topology accordingly.
Next steps
Get Started with Kafka Service
Create a native Kafka Cluster and produce your first message.
Kafka on Pulsar Clusters
Set up Kafka compatibility on your existing Pulsar Clusters using KSN.