Native Apache Kafka Service Is Coming Soon to StreamNative Cloud. Join the waitlist and get $1,000 in credits.
Join Waitlist >
Choose Pulsar or Kafka
StreamNative Cloud offers both Pulsar and Kafka clusters — both powered by the Ursa engine and Lakestream architecture. Choose the right cluster type for your workload.
Same Ursa Engine
Both Pulsar and Kafka clusters are powered by the same lakehouse-native Ursa engine with Iceberg and Delta Lake integration.
Messaging + Streaming
Pulsar for queuing and messaging, Kafka for event streaming — or use Pulsar for both in a single cluster.
Open Standards
No vendor lock-in. Open protocols (Pulsar, Kafka, REST) and open table formats (Iceberg, Delta Lake).
• AT A GLANCE
Pulsar vs Kafka on StreamNative Cloud
Both cluster types are powered by the Ursa engine and the Lakestream architecture. Here's how they compare.
• CLUSTER SELECTION
When to Choose Each
Both cluster types are powered by the Ursa engine. Your choice depends on your workload pattern and existing infrastructure.
Choose Pulsar Cluster
- Messaging & queuing workloads: task queues, job dispatch, command routing, request-reply patterns
- Multi-tenant messaging with namespace and tenant isolation
- Unified messaging: pub-sub + queuing + streaming, in only one cluster
- Existing Pulsar workloads — stay on what works
Choose Kafka Cluster
- Event streaming workloads: event sourcing, log aggregation, clickstream, IoT telemetry, change data capture
- Existing Kafka workloads looking for lift-and-shift modernization
- Teams that require native Apache Kafka API behavior (not a compatibility layer)
- High-throughput event streaming where Kafka is the ecosystem standard
• UNDERSTANDING THE DIFFERENCE
Messaging vs Streaming
If you need both messaging and streaming semantics in one cluster, Pulsar Cluster handles both natively. If your workloads are purely event streaming, Kafka Cluster is the natural fit.
Messaging (Pulsar's Strength)
Consumer-centric delivery. Messages are dispatched to individual consumers, acknowledged, and removed. Patterns: task queues, work distribution, request-reply, command routing. Key feature: shared subscriptions for competing consumers.
Streaming (Kafka's Strength)
Log-centric processing. Events are appended to a durable, ordered log. Consumers read at their own pace with offsets. Patterns: event sourcing, stream processing, replay, CDC, analytics pipelines. Key feature: consumer groups with partition assignment.
What About Both?
If you need both messaging and streaming semantics in one cluster, Pulsar Cluster handles both natively. If your workloads are purely event streaming, Kafka Cluster is the natural fit.
• QUICK DECISION GUIDE
Start Making Your Decision Here
Choose a cluster type based on your current situation.
Step 1:
Greenfield or Brownfield?
Greenfield
New Project, No Existing Streaming Infrastructure
Pulsar handles messaging, queuing, and streaming in one unified system with multi-tenancy, multi-protocol support (Pulsar + Kafka + REST), and built-in geo-replication. It’s the most versatile starting point.
Brownfield
Existing Streaming Infrastructure
Pulsar handles messaging, queuing, and streaming in one unified system with multi-tenancy, multi-protocol support (Pulsar + Kafka + REST), and built-in geo-replication. It’s the most versatile starting point.
Step 2:
What Existing Technology Are You Using?
Running Pulsar
Already on Pulsar
Stay on Pulsar — no changes needed. Simply onboard your existing cluster to StreamNative.
Running Kafka
On Kafka — Self-Managed, MSK, or Confluent, but Want to Modernize
Migrate to native Kafka with lakehouse-native storage. Lift-and-shift via Universal Linking keeps your existing pipelines intact.
Running Kafka
Only Need Kafka Wire-Protocol Compatibility
Pulsar Cluster with Kafka protocol (KoP/KSN) may suffice — simpler if you also need messaging and queuing alongside Kafka workloads.
Running Both
Both Pulsar and Kafka in Use
Run both cluster types on the same StreamNative instance, unified under one platform with shared management and observability.
Running Other
RabbitMQ, ActiveMQ, or Other Messaging
Pulsar Cluster is the closest model for messaging and queuing workloads, making migration from traditional brokers straightforward.
• STORAGE PROFILES
Choose Storage Profile Based on Your Workload
Select between latency-optimized and cost-optimized when creating your cluster. Kafka clusters support mixing both profiles.
Latency-Optimized
Single-digit millisecond latency with disk-based storage. Best for real-time transaction processing, fraud detection, and event-driven microservices.
Cost-Optimized
Sub-second latency with diskless, lakehouse-native storage. Up to 95% cost reduction. Best for IoT/telemetry, lakehouse pipelines, clickstream, and high-volume streaming.
FAQs
No. Pulsar is a first-class product on StreamNative Cloud. All Pulsar clusters are powered by the same Ursa engine that powers Kafka clusters. StreamNative continues to invest in Pulsar — it remains the best choice for multi-tenant messaging, queuing, and workloads requiring unified pub-sub + queuing + streaming.
StreamNative has always supported Kafka workloads via Kafka-on-StreamNative (KSN), a Kafka compatibility layer on Pulsar. The new Kafka Cluster is the next step: native Apache Kafka 4.0+ powered by the Ursa engine. This gives customers who need native Kafka semantics a first-class option, without affecting Pulsar customers. Both, not either.
Nothing. Existing Pulsar clusters continue to run unchanged. Same Ursa engine, same SLAs (up to 99.99% multi-zone), same support. The only change is that you now have additional cluster types available when creating new resources.
Ursa is StreamNative's lakehouse-native storage engine (VLDB 2025 Best Industry Paper). It powers all clusters on StreamNative Cloud — both Pulsar and Kafka. This means both cluster types benefit from lakehouse-native storage, open table formats (Iceberg, Delta Lake), and the Lakestream architecture.
No. If your workloads are running on Pulsar, stay on Pulsar. Pulsar handles messaging, queuing, and streaming in one unified system — there is no reason to migrate. The Kafka Cluster is designed for customers with existing Kafka workloads who want to modernize with lakehouse-native storage. It is not a replacement for Pulsar.
Pulsar excels at messaging and queuing workloads: task distribution, work queues, request-reply patterns, and scenarios requiring shared/failover/key-shared subscriptions. Pulsar also shines when you need multi-tenancy (namespaces/tenants), built-in geo-replication, or a unified system that handles pub-sub, queuing, and streaming in one cluster. For greenfield projects, Pulsar is the recommended starting point because it supports all patterns and all protocols (Pulsar + Kafka + REST) in one cluster.
Yes. Pulsar Clusters support Pulsar, Kafka, and REST protocols. If you only need Kafka wire-protocol compatibility on Pulsar infrastructure, a Pulsar Cluster with Kafka-on-StreamNative (KSN) may be sufficient. The dedicated Kafka Cluster is for teams that need native Apache Kafka (not a compatibility layer).
Both Pulsar and Kafka clusters offer latency-optimized and cost-optimized storage profiles. Cost-optimized delivers sub-second latency with diskless, lakehouse-native storage at up to 95% cost reduction. Latency-optimized provides single-digit millisecond latency with disk-based storage. Both profiles can coexist in the same cluster — choose per topic.
Yes. You can run both Pulsar and Kafka cluster types on the same StreamNative Cloud instance, unified under one platform. This is ideal for organizations that have both messaging/queuing workloads (Pulsar) and event streaming workloads (Kafka).
Start with the workload pattern. Pulsar is the stronger choice for messaging and queuing, task distribution, request-reply patterns, and multi-tenant environments — it was designed for these use cases. Kafka is the right fit when you need native Kafka ecosystem compatibility, are migrating from self-managed Kafka, or your team already has deep Kafka expertise. Both run on the same Ursa engine with the same SLAs, so the decision is about protocol fit, not infrastructure quality.
Ready to get started?
- Spin up a Pulsar or Kafka cluster in minutes on StreamNative Cloud.
- Point your existing clients at the new endpoint — no code changes for Kafka workloads.
- Run both cluster types on the same platform, unified under one bill.