Skip to main content
On this page

​
Coverage by target cloud

​
How the targets compare

Each row compares a capability of Kinesis with its adaptation on each target. A dash means this row is not stated for that target.

​
Max adaptation

​
Runtime surface

​
Limits

​
On Google Cloud

​
Via Pub/Sub

​
Ordered messages without addressable shards

The adapter maps the Kinesis stream to a Pub/Sub topic and uses the partition key as an ordering key. This preserves the intended order within a key, but Pub/Sub does not expose Kinesis hash ranges or a fixed set of addressable shards. ExplicitHashKey and split/merge operations cannot be represented by that ordering-key mapping. Reads drain a Pub/Sub subscription. Pub/Sub can seek by timestamp or snapshot; it does not expose a Kafka-style offset for each message. A returned sequence number therefore cannot promise exact-message replay. Review any consumer that persists a sequence number and later expects to resume at exactly that record.

​
Consumers, retention and cutover

Separate subscriptions give fan-out consumers separate copies and delivery state. Google controls subscription delivery and capacity; the Kinesis dedicated-throughput guarantee does not apply to this target. Kinesis Client Library applications still need their separate DynamoDB lease table through a compatible adapter. Pub/Sub retention is limited to the profile’s stated window. Provision subscriptions before publication, test restart and replay behavior, and verify that the consumer can work without addressable shard positions. Existing AWS records and checkpoint positions are not copied. Measure adapter latency, backlog and consumer progress together; topic acceptance alone does not establish end-to-end processing speed.

​
Via Managed Service for Apache Kafka

​
From a shard to a target partition

The application calls the Kinesis API on the Tensor9 adapter; the adapter uses Google’s Managed Service for Apache Kafka for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log.

​
Consumer state and capacity

The retained log and the consumer’s progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer’s restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target’s capacity replaces Kinesis’s dedicated per-consumer throughput guarantee.

​
Operating and moving the stream

Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application’s record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream.

​
On Google Cloud and Private Kubernetes

​
Via Strimzi Kafka

​
From a shard to a target partition

The application calls the Kinesis API on the Tensor9 adapter; the adapter uses Apache Kafka (Strimzi) on the target cluster for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log.

​
Consumer state and capacity

The retained log and the consumer’s progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer’s restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target’s capacity replaces Kinesis’s dedicated per-consumer throughput guarantee.

​
Operating and moving the stream

Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application’s record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream.

​
On Azure

​
From a shard to a target partition

The application calls the Kinesis API on the Tensor9 adapter; the adapter uses Azure Event Hubs for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log.

​
Consumer state and capacity

The retained log and the consumer’s progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer’s restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target’s capacity replaces Kinesis’s dedicated per-consumer throughput guarantee.

​
Operating and moving the stream

Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application’s record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream.

​
On OCI

​
From a shard to a target partition

The application calls the Kinesis API on the Tensor9 adapter; the adapter uses OCI Streaming for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log.

​
Consumer state and capacity

The retained log and the consumer’s progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer’s restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target’s capacity replaces Kinesis’s dedicated per-consumer throughput guarantee.

​
Operating and moving the stream

Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application’s record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream. Service Catalog.