If you know Kafka and encounter Pulsar terms in our docs (or vice versa), use this reference to translate between the two protocols.
Core concepts mapping
The following table maps common Kafka concepts to their Pulsar equivalents. Where a concept exists in one protocol but not the other, the cell is marked with a dash.
| Kafka Concept | Pulsar Equivalent | Notes |
|---|
| Topic | Topic | Same concept. Both protocols use topics as the primary unit for organizing messages. |
| Partition | Partition | Pulsar topics also have partitions. Both protocols use partitions for parallelism and ordering. |
| Consumer Group | Subscription (Failover) | A Failover subscription provides one active consumer with automatic failover to standby consumers, similar to how Kafka consumer groups assign partitions to consumers. |
| Offset | Message ID / Cursor | Pulsar uses message IDs for position tracking instead of numeric offsets. |
| — | Tenant | Pulsar’s top-level isolation boundary. Kafka Service does not use tenants. |
| — | Namespace | Pulsar’s logical grouping under a tenant. Kafka Service does not use namespaces. |
| Bootstrap Server | Service URL | The connection endpoint for the cluster. |
| Producer | Producer | Same concept. Both protocols use producers to publish messages to topics. |
| Consumer | Consumer | Same concept. Both protocols use consumers to read messages from topics. |
| Kafka Connect | Pulsar IO | Connector frameworks for integrating external systems. StreamNative supports both. |
| Kafka Streams | Pulsar Functions | Stream processing frameworks. Kafka Streams is a client library; Pulsar Functions run server-side. |
| StreamNative Kafka Schema Registry | Built-in Schema Registry | StreamNative Kafka Schema Registry is compatible with Confluent Schema Registry. |
| Retention Policy | Retention Policy | Both Kafka and Pulsar have similar retention policy concepts for controlling how long messages are stored. |
Key differences
Multi-tenancy
Pulsar provides built-in multi-tenancy through tenants and namespaces. Tenants serve as the top-level isolation boundary, and namespaces group related topics under a tenant. This hierarchy enables fine-grained access control and resource isolation.
Kafka Service on StreamNative Cloud works with topics directly and does not expose the tenant or namespace layer to users.
Subscription types
Pulsar offers four subscription types that control how messages are delivered to consumers:
- Exclusive: Only one consumer can attach to a subscription.
- Shared: Multiple consumers receive messages in round-robin fashion.
- Failover: One active consumer with automatic failover to standby consumers (similar to Kafka consumer groups).
- Key_Shared: Messages with the same key are delivered to the same consumer while allowing multiple consumers on a subscription.
Kafka uses consumer groups with partition-based assignment. Each partition is assigned to exactly one consumer within a group. Kafka also supports queues as a newer delivery model that allows multiple consumers to share work without partition affinity, similar to Pulsar’s shared subscriptions.
Geo-replication
Pulsar has built-in cross-cluster replication that synchronizes data across clusters in different regions. You configure replication at the namespace or topic level.
For Kafka protocol on StreamNative Cloud, use Universal Linking to replicate data across clusters.
Cluster types
StreamNative Cloud offers two cluster types:
- Kafka Clusters: Run native Apache Kafka. Only Kafka clients can connect to Kafka Clusters.
- Pulsar Clusters: Run native Apache Pulsar. Both Pulsar clients and Kafka clients (through KSN) can connect to Pulsar Clusters that have KSN enabled.
On StreamNative Cloud, both cluster types run on the Ursa Engine. The differences are at the API and cluster type level, not the storage level. You can choose the cluster type that best fits your application without affecting durability, performance, or operational overhead.
