Kinesis Data Stream

Preview On this page

• Coverage by target cloud
• How the backends compare
  • Max adaptation
• On Google Cloud
  • Via Pub/Sub
  • Via Managed Service for Apache Kafka
• On Google Cloud and Private Kubernetes
  • Via Strimzi Kafka
• On Azure
• On OCI
• Costs
• Service level agreements
  • Kinesis Data Stream to Azure Event Hubs
  • Kinesis Data Stream to Managed Service for Apache Kafka
  • Kinesis Data Stream to Pub/Sub
  • Kinesis Data Stream to OCI Streaming
  • Kinesis Data Stream to Strimzi Kafka
• Debug this service

​

Coverage by target cloud

​

How the backends compare

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

​

Max adaptation

​

Runtime surface

​

Limits

​

On Google Cloud

​

Via Pub/Sub

​

How it works

Your application keeps calling the Kinesis API on the Tensor9 adapter, which maps the stream to a Pub/Sub topic and uses each record’s partition key as the Pub/Sub ordering key. Records with the same key stay in order. Pub/Sub has no hash ranges and no fixed set of addressable shards. Reads pull from a Pub/Sub subscription. Separate subscriptions give fan-out consumers their own copy of the messages and their own delivery state. Pub/Sub can replay from a timestamp or a snapshot, but it has no per-message offset, so a returned sequence number cannot promise replay from exactly that record.

​

Limitations

• ExplicitHashKey, shard splits and merges are not supported. The ordering-key mapping cannot represent them. - Replay from an exact sequence number is not supported. Review any consumer that saves a sequence number and later expects to resume at exactly that record. - Dedicated throughput per consumer is not supported. Google controls subscription delivery and capacity. - Retention behaves differently: it is about 31 days at most. Pub/Sub cannot keep records for the 365 days Kinesis allows. - You must provide the KCL lease table. Kinesis Client Library applications still need their DynamoDB lease table, through a compatible DynamoDB adapter.

​

Other considerations

Before cutover. Create subscriptions before publishing, test restart and replay, and confirm your consumers work without addressable shard positions. Existing AWS records and checkpoints are not copied. What to monitor. Measure adapter latency, backlog and consumer progress together; a topic accepting a message does not show how fast it is processed end to end.

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

Monthly cost by provisioned Kinesis shards

Reference monthly service charges by Provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions

• 100 records/s per provisioned source shard, each 1 KiB; one full-stream consumer; 730 hours/month. Pub/Sub retains the physical stream at topic level for 24 hours, including 64 bytes of assumed overhead per record. Source shard count and traffic are authored scenario choices, not measured adapter throughput or semantic equivalence.
• Monthly AWS source usage in us-east-1, priced at the 2026-10-18 reference list rates before free allowances, discounts, credits and tax; not the uploaded invoice total. Rates as of 2026-10-18: us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Provisioned Kinesis, 24-hour retention and shared-throughput consumers only; on-demand, enhanced fan-out and extended retention use different pricing.
• Pub/Sub publishes and delivers each full consumer copy, and retains the physical stream for 24 hours at topic level for replay. Steady traffic over 730 hours is assumed.
• Pub/Sub ordering keys do not reproduce addressable shards or exact per-record offsets. This pricing comparison does not qualify semantic compatibility or throughput.
• Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources.
• Kinesis Data Streams provisioned pricing: https://aws.amazon.com/kinesis/data-streams/pricing/
• Pub/Sub throughput and retained-message pricing: https://cloud.google.com/pubsub/pricing

Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied. Excluded costs and workload features:

• Free allowances, negotiated discounts, credits, tax and one-time migration charges.
• Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS.
• Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure.
• KCL DynamoDB lease-table costs, replay/redelivery beyond the declared consumer copies, snapshots and extra subscriptions.

Rate snapshot: 2026-10-18. Model: kinesis-pubsub / 2026-10-18.4. Curve: provisioned-shards. Sources: Kinesis Data Streams provisioned pricing, Pub/Sub throughput and retained-message pricing. Kinesis Data Streams → Google Cloud Pub/Sub: Reference monthly workload. Monthly AWS usage charges at the 2026-10-18 reference list rates in us-east-1, before free allowances, discounts, credits and tax. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. Unestimated components: Allocated adapter hosting, Allocated Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied. Excluded costs and workload features:

• Free allowances, negotiated discounts, credits, tax and one-time migration charges.
• Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS.
• Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure.
• KCL DynamoDB lease-table costs, replay/redelivery beyond the declared consumer copies, snapshots and extra subscriptions.

Scenario assumptions

• Provisioned origin shard-hours: 730 shard-hours/month.
• Inferred original stream records: 262,800,000 records/month.
• Steady 24-hour physical retained stream: 8.755 GiB.
• Provisioned Kinesis, 24-hour retention and shared-throughput consumers only; on-demand, enhanced fan-out and extended retention use different pricing.
• Pub/Sub publishes and delivers each full consumer copy, and retains the physical stream for 24 hours at topic level for replay. Steady traffic over 730 hours is assumed.
• Pub/Sub ordering keys do not reproduce addressable shards or exact per-record offsets. This pricing comparison does not qualify semantic compatibility or throughput.

Rate snapshot: 2026-10-18. Model: kinesis-pubsub / 2026-10-18.4. Scenario: kinesis-pubsub-reference. Sources: Kinesis Data Streams provisioned pricing, Pub/Sub throughput and retained-message pricing.

​

Via Managed Service for Apache Kafka

​

How it works

Your application keeps calling the Kinesis API, now on the Tensor9 adapter, and the adapter stores the record log on Google’s Managed Service for Apache Kafka. Each Kinesis shard maps to a partition there. Partition-key hashing chooses the shard, and the partition’s ordered position becomes part of the sequence number the call returns. Consumers get an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records, and getting an iterator at a retained position lets you replay. These positions belong to the new stream: existing AWS sequence numbers and checkpoints do not point at anything in the new log.

​

Consumer state and capacity

The record log and each consumer’s progress are kept separately. Kinesis Client Library (KCL) applications also keep leases and checkpoints in a DynamoDB table. Deploy a compatible DynamoDB adapter with this stream and test how the consumer restarts and reassigns shards; keeping the Kinesis endpoint alone does not provide that table. Retention is set on Google’s Managed Service for Apache Kafka and is limited by the provider’s limits in the comparison table. Record size, uneven partitions, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with your own record sizes and partition distribution.

​

Limitations

• Shard split and merge history is not supported. The partition count is fixed. Adding partitions changes routing for some keys, so plan that change with your consumers instead of assuming existing shard positions stay valid. - Enhanced fan-out behaves differently: there is no dedicated throughput per consumer. It uses consumer groups on Google’s Managed Service for Apache Kafka, so that service’s capacity applies instead of Kinesis’s per-consumer guarantee. - Moving AWS records, sequence numbers and checkpoints is not supported. The new stream starts empty, and old positions do not identify records in it.

​

Other considerations

Before cutover. Create the stream and the consumer checkpoint store first. Drain the old stream, or publish to both while consumers catch up. What to monitor. Use Google’s Managed Service for Apache Kafka partition metrics and adapter metrics to watch reads, writes and lag; AWS CloudWatch series do not move with the stream.

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

Monthly cost by provisioned Kinesis shards

Reference monthly service charges by Provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions

• 100 records/s per source shard, each 1 KiB; one full-stream consumer; 24-hour retention; 730 hours/month. The target remains a named 3-vCPU/12-GiB cluster with 300 GiB local disk: its throughput is unqualified. The full retained physical stream is also allocated to single-copy long-term storage, a conservative storage scenario; actual tier placement can reduce it. Three replicas and their inter-zone transfer are priced; same-zone clients and local follower reads are assumed.
• Monthly AWS source usage in us-east-1, priced at the 2026-10-18 reference list rates before free allowances, discounts, credits and tax; not the uploaded invoice total. Rates as of 2026-10-18: us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Provisioned Kinesis with 24-hour retention and shared-read consumers; 730 running hours. Google Managed Kafka uses three replicas across zones.
• Cluster allocation pricing only: throughput, peak load, retention suitability and latency remain unqualified. The curve does not resize compute automatically.
• Compute is USD 0.09 per DCU-hour; one vCPU is 0.6 DCU and one GiB RAM is 0.1 DCU. All local disk is charged, plus the explicitly selected single-copy long-term storage allocation.
• Replication transfers two physical copies at USD 0.01/GiB. Same-zone client traffic assumes local follower reads; extra client traffic must be supplied separately.
• Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources.
• Kinesis Data Streams provisioned pricing: https://aws.amazon.com/kinesis/data-streams/pricing/
• Google Managed Kafka pricing: https://cloud.google.com/managed-service-for-apache-kafka/pricing
• Managed Kafka capacity configuration: https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/create-cluster

Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied. Excluded costs and workload features:

• Free allowances, negotiated discounts, credits, tax and one-time migration charges.
• Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS.
• Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure.
• KCL DynamoDB lease-table costs, Connect clusters, extra replication/consumer copies, unsupported resharding behavior and unqualified cluster capacity.

Rate snapshot: 2026-10-18. Model: kinesis-managed-kafka / 2026-10-18.4. Curve: provisioned-shards. Sources: Kinesis Data Streams provisioned pricing, Google Managed Kafka pricing, Managed Kafka capacity configuration. Kinesis Data Streams → Google Managed Kafka: Reference monthly workload. Monthly AWS usage charges at the 2026-10-18 reference list rates in us-east-1, before free allowances, discounts, credits and tax. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. Unestimated components: Allocated adapter hosting, Allocated Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied. Excluded costs and workload features:

• Free allowances, negotiated discounts, credits, tax and one-time migration charges.
• Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS.
• Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure.
• KCL DynamoDB lease-table costs, Connect clusters, extra replication/consumer copies, unsupported resharding behavior and unqualified cluster capacity.

Scenario assumptions

• Provisioned origin shard-hours: 730 shard-hours/month.
• Inferred original stream records: 262,800,000 records/month.
• Steady 24-hour physical retained stream: 8.755 GiB.
• Provisioned Kinesis with 24-hour retention and shared-read consumers; 730 running hours. Google Managed Kafka uses three replicas across zones.
• Cluster allocation pricing only: throughput, peak load, retention suitability and latency remain unqualified. The curve does not resize compute automatically.
• Compute is USD 0.09 per DCU-hour; one vCPU is 0.6 DCU and one GiB RAM is 0.1 DCU. All local disk is charged, plus the explicitly selected single-copy long-term storage allocation.
• Replication transfers two physical copies at USD 0.01/GiB. Same-zone client traffic assumes local follower reads; extra client traffic must be supplied separately.

Rate snapshot: 2026-10-18. Model: kinesis-managed-kafka / 2026-10-18.4. Scenario: kinesis-managed-kafka-reference. Sources: Kinesis Data Streams provisioned pricing, Google Managed Kafka pricing, Managed Kafka capacity configuration.

​

On Google Cloud and Private Kubernetes

​

Via Strimzi Kafka

​

How it works

Your application keeps calling the Kinesis API, now on the Tensor9 adapter, and the adapter stores the record log on Apache Kafka (Strimzi) on the target cluster. Each Kinesis shard maps to a partition there. Partition-key hashing chooses the shard, and the partition’s ordered position becomes part of the sequence number the call returns. Consumers get an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records, and getting an iterator at a retained position lets you replay. These positions belong to the new stream: existing AWS sequence numbers and checkpoints do not point at anything in the new log.

​

Consumer state and capacity

The record log and each consumer’s progress are kept separately. Kinesis Client Library (KCL) applications also keep leases and checkpoints in a DynamoDB table. Deploy a compatible DynamoDB adapter with this stream and test how the consumer restarts and reassigns shards; keeping the Kinesis endpoint alone does not provide that table. Retention is set on Apache Kafka (Strimzi) on the target cluster and is limited by the provider’s limits in the comparison table. Record size, uneven partitions, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with your own record sizes and partition distribution.

​

Limitations

• Shard split and merge history is not supported. The partition count is fixed. Adding partitions changes routing for some keys, so plan that change with your consumers instead of assuming existing shard positions stay valid. - Enhanced fan-out behaves differently: there is no dedicated throughput per consumer. It uses consumer groups on Apache Kafka (Strimzi) on the target cluster, so that service’s capacity applies instead of Kinesis’s per-consumer guarantee. - Moving AWS records, sequence numbers and checkpoints is not supported. The new stream starts empty, and old positions do not identify records in it.

​

Other considerations

Before cutover. Create the stream and the consumer checkpoint store first. Drain the old stream, or publish to both while consumers catch up. What to monitor. Use Apache Kafka (Strimzi) on the target cluster partition metrics and adapter metrics to watch reads, writes and lag; AWS CloudWatch series do not move with the stream.

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

Kinesis Data Streams · PUT payload units

Feature: Kinesis Data Streams. Estimated monthly service charges by PUT payload units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 16 vCPU, 87.75 GiB memory and 1,120 GiB SSD at 10,000 per second. Curve assumptions

• Payload size determines physical record and byte throughput. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
• A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
• Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
• A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
• Self-hosted target: Strimzi and Apache Kafka (Apache-2.0, https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE); Kafka replication multiplies disk beyond the copies this model bills. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• Broker CPU follows write-equivalent bytes; the row-store operations coefficient is not applied.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AmazonKinesis offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json
• Compute Engine general-purpose machine pricing: https://cloud.google.com/products/compute/pricing/general-purpose
• Disk and image pricing: https://cloud.google.com/compute/disks-image-pricing
• Network pricing: https://cloud.google.com/vpc/network-pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
• Destination application execution and separately billed downstream services; supply those allocations separately.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-345e11fb79eca5767bb2e6fcf2891ab45eff792c / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonKinesis offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

Kinesis Data Streams · Origin provisioned shards

Feature: Kinesis Data Streams. Estimated monthly service charges by Origin provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. Curve assumptions

• Provisioned capacity alone does not reveal actual record traffic; PUT meter stays independent. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
• A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
• Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
• A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
• Self-hosted target: Strimzi and Apache Kafka (Apache-2.0, https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE); Kafka replication multiplies disk beyond the copies this model bills. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• Broker CPU follows write-equivalent bytes; the row-store operations coefficient is not applied.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AmazonKinesis offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json
• Compute Engine general-purpose machine pricing: https://cloud.google.com/products/compute/pricing/general-purpose
• Disk and image pricing: https://cloud.google.com/compute/disks-image-pricing
• Network pricing: https://cloud.google.com/vpc/network-pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
• Destination application execution and separately billed downstream services; supply those allocations separately.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-345e11fb79eca5767bb2e6fcf2891ab45eff792c / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonKinesis offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing. Kinesis Data Streams → Strimzi Kafka: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
• Destination application execution and separately billed downstream services; supply those allocations separately.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

Scenario assumptions

• Translated reads: 0 operations.
• Translated writes: 0 operations.
• Translated resident physical data: 0 GiB-month.
• Native provider operations: 0 operations.
• Published payload: 0 GiB.
• Delivered payload: 0 GiB.
• Allocated execution CPU: 0 vCPU-hour.
• Allocated execution RAM: 0 GiB-hour.
• Independent resource allocation: 0 resource-hour.
• Independent inventory: 0 resource-month.
• Input tokens: 0 tokens.
• Output tokens: 0 tokens.
• Billable network: 0 GiB.
• Dependent object sink retained data: 0 GiB-month.
• Dependent object sink writes: 0 writes.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
• A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
• Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
• A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
• Self-hosted target: Strimzi and Apache Kafka (Apache-2.0, https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE); Kafka replication multiplies disk beyond the copies this model bills. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• Broker CPU follows write-equivalent bytes; the row-store operations coefficient is not applied.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: plan-345e11fb79eca5767bb2e6fcf2891ab45eff792c / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonKinesis offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

​

On Azure

​

How it works

Your application keeps calling the Kinesis API, now on the Tensor9 adapter, and the adapter stores the record log on Azure Event Hubs. Each Kinesis shard maps to a partition there. Partition-key hashing chooses the shard, and the partition’s ordered position becomes part of the sequence number the call returns. Consumers get an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records, and getting an iterator at a retained position lets you replay. These positions belong to the new stream: existing AWS sequence numbers and checkpoints do not point at anything in the new log.

​

Consumer state and capacity

The record log and each consumer’s progress are kept separately. Kinesis Client Library (KCL) applications also keep leases and checkpoints in a DynamoDB table. Deploy a compatible DynamoDB adapter with this stream and test how the consumer restarts and reassigns shards; keeping the Kinesis endpoint alone does not provide that table. Retention is set on Azure Event Hubs and is limited by the provider’s limits in the comparison table. Record size, uneven partitions, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with your own record sizes and partition distribution.

​

Limitations

• Shard split and merge history is not supported. The partition count is fixed. Adding partitions changes routing for some keys, so plan that change with your consumers instead of assuming existing shard positions stay valid. - Enhanced fan-out behaves differently: there is no dedicated throughput per consumer. It uses consumer groups on Azure Event Hubs, so that service’s capacity applies instead of Kinesis’s per-consumer guarantee. - Moving AWS records, sequence numbers and checkpoints is not supported. The new stream starts empty, and old positions do not identify records in it.

​

Other considerations

Before cutover. Create the stream and the consumer checkpoint store first. Drain the old stream, or publish to both while consumers catch up. What to monitor. Use Azure Event Hubs partition metrics and adapter metrics to watch reads, writes and lag; AWS CloudWatch series do not move with the stream.

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

Kinesis Data Streams · PUT payload units

Feature: Kinesis Data Streams. Estimated monthly service charges by PUT payload units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: East US; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions

• Payload size determines physical record and byte throughput. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → East US, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
• A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
• Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
• A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
• Azure Event Hubs Standard bills throughput-unit hours, sized here from the family’s published and delivered bytes and its ingress (write) and egress (read) event rates against one unit’s published limits, never below one unit (USD 21.90/month). Ingress events also bill USD 0.028 per million; each family write is one event, and events over 64 KB, which bill as several, are not split. Up to 84 GB of storage per unit is included, so retained data adds no charge. Capture, when enabled, bills USD 0.10 per throughput-unit hour and is not modeled.
• AWS Price List API, AmazonKinesis offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
• Destination application execution and separately billed downstream services; supply those allocations separately.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-50b2735e718e9d039b897f1878bcc337362c365f / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonKinesis offer, Azure Retail Prices API.

Kinesis Data Streams · Origin provisioned shards

Feature: Kinesis Data Streams. Estimated monthly service charges by Origin provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: East US; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions

• Provisioned capacity alone does not reveal actual record traffic; PUT meter stays independent. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → East US, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
• A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
• Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
• A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
• Azure Event Hubs Standard bills throughput-unit hours, sized here from the family’s published and delivered bytes and its ingress (write) and egress (read) event rates against one unit’s published limits, never below one unit (USD 21.90/month). Ingress events also bill USD 0.028 per million; each family write is one event, and events over 64 KB, which bill as several, are not split. Up to 84 GB of storage per unit is included, so retained data adds no charge. Capture, when enabled, bills USD 0.10 per throughput-unit hour and is not modeled.
• AWS Price List API, AmazonKinesis offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
• Destination application execution and separately billed downstream services; supply those allocations separately.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-50b2735e718e9d039b897f1878bcc337362c365f / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonKinesis offer, Azure Retail Prices API. Kinesis Data Streams → Azure Event Hubs: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: East US. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
• Destination application execution and separately billed downstream services; supply those allocations separately.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

Scenario assumptions

• Translated reads: 0 operations.
• Translated writes: 0 operations.
• Translated resident physical data: 0 GiB-month.
• Native provider operations: 0 operations.
• Published payload: 0 GiB.
• Delivered payload: 0 GiB.
• Allocated execution CPU: 0 vCPU-hour.
• Allocated execution RAM: 0 GiB-hour.
• Independent resource allocation: 0 resource-hour.
• Independent inventory: 0 resource-month.
• Input tokens: 0 tokens.
• Output tokens: 0 tokens.
• Billable network: 0 GiB.
• Dependent object sink retained data: 0 GiB-month.
• Dependent object sink writes: 0 writes.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
• A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
• Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
• A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
• Azure Event Hubs Standard bills throughput-unit hours, sized here from the family’s published and delivered bytes and its ingress (write) and egress (read) event rates against one unit’s published limits, never below one unit (USD 21.90/month). Ingress events also bill USD 0.028 per million; each family write is one event, and events over 64 KB, which bill as several, are not split. Up to 84 GB of storage per unit is included, so retained data adds no charge. Capture, when enabled, bills USD 0.10 per throughput-unit hour and is not modeled.

List prices read: 2026-10-22. Model: plan-50b2735e718e9d039b897f1878bcc337362c365f / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonKinesis offer, Azure Retail Prices API.

​

On OCI

​

How it works

Your application keeps calling the Kinesis API, now on the Tensor9 adapter, and the adapter stores the record log on OCI Streaming. Each Kinesis shard maps to a partition there. Partition-key hashing chooses the shard, and the partition’s ordered position becomes part of the sequence number the call returns. Consumers get an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records, and getting an iterator at a retained position lets you replay. These positions belong to the new stream: existing AWS sequence numbers and checkpoints do not point at anything in the new log.

​

Consumer state and capacity

The record log and each consumer’s progress are kept separately. Kinesis Client Library (KCL) applications also keep leases and checkpoints in a DynamoDB table. Deploy a compatible DynamoDB adapter with this stream and test how the consumer restarts and reassigns shards; keeping the Kinesis endpoint alone does not provide that table. Retention is set on OCI Streaming and is limited by the provider’s limits in the comparison table. Record size, uneven partitions, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with your own record sizes and partition distribution.

​

Limitations

• Shard split and merge history is not supported. The partition count is fixed. Adding partitions changes routing for some keys, so plan that change with your consumers instead of assuming existing shard positions stay valid. - Enhanced fan-out behaves differently: there is no dedicated throughput per consumer. It uses consumer groups on OCI Streaming, so that service’s capacity applies instead of Kinesis’s per-consumer guarantee. - Moving AWS records, sequence numbers and checkpoints is not supported. The new stream starts empty, and old positions do not identify records in it.

​

Other considerations

Before cutover. Create the stream and the consumer checkpoint store first. Drain the old stream, or publish to both while consumers catch up. What to monitor. Use OCI Streaming partition metrics and adapter metrics to watch reads, writes and lag; AWS CloudWatch series do not move with the stream.

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

Kinesis Data Streams · PUT payload units

Feature: Kinesis Data Streams. Estimated monthly service charges by PUT payload units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (OCI global price list); currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions

• Payload size determines physical record and byte throughput. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-ashburn-1 (OCI global price list), USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
• A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
• Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
• A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
• OCI Streaming bills PUT and GET bytes and retained GB-hours, with no partition charge within the default service limits; beyond them OCI expects at least 10 GB/hour of PUT and GET per 50 partitions. Retention defaults to 24 hours, up to 7 days.
• AWS Price List API, AmazonKinesis offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json
• OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
• Destination application execution and separately billed downstream services; supply those allocations separately.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-9811d8ea456c7e42af3f0509a197ed3539f77d7f / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonKinesis offer, OCI price list API.

Kinesis Data Streams · Origin provisioned shards

Feature: Kinesis Data Streams. Estimated monthly service charges by Origin provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (OCI global price list); currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions

• Provisioned capacity alone does not reveal actual record traffic; PUT meter stays independent. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-ashburn-1 (OCI global price list), USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
• A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
• Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
• A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
• OCI Streaming bills PUT and GET bytes and retained GB-hours, with no partition charge within the default service limits; beyond them OCI expects at least 10 GB/hour of PUT and GET per 50 partitions. Retention defaults to 24 hours, up to 7 days.
• AWS Price List API, AmazonKinesis offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json
• OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
• Destination application execution and separately billed downstream services; supply those allocations separately.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-9811d8ea456c7e42af3f0509a197ed3539f77d7f / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonKinesis offer, OCI price list API. Kinesis Data Streams → OCI Streaming: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-ashburn-1 (OCI global price list). Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
• Destination application execution and separately billed downstream services; supply those allocations separately.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

Scenario assumptions

• Translated reads: 0 operations.
• Translated writes: 0 operations.
• Translated resident physical data: 0 GiB-month.
• Native provider operations: 0 operations.
• Published payload: 0 GiB.
• Delivered payload: 0 GiB.
• Allocated execution CPU: 0 vCPU-hour.
• Allocated execution RAM: 0 GiB-hour.
• Independent resource allocation: 0 resource-hour.
• Independent inventory: 0 resource-month.
• Input tokens: 0 tokens.
• Output tokens: 0 tokens.
• Billable network: 0 GiB.
• Dependent object sink retained data: 0 GiB-month.
• Dependent object sink writes: 0 writes.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
• A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
• Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
• A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
• OCI Streaming bills PUT and GET bytes and retained GB-hours, with no partition charge within the default service limits; beyond them OCI expects at least 10 GB/hour of PUT and GET per 50 partitions. Retention defaults to 24 hours, up to 7 days.

List prices read: 2026-10-22. Model: plan-9811d8ea456c7e42af3f0509a197ed3539f77d7f / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonKinesis offer, OCI price list API.

​

Costs

Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model’s cost curve. Adapter hosting and Tensor9 fees are excluded. How Tensor9 estimates costs explains the method, what the estimates include and how to read their qualifications. Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row’s difference at its stated workload rather than charges across rows. Cost curves across workload sizes, with every assumption and exclusion: Amazon Kinesis costs.

​

Service level agreements

Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.

​

Kinesis Data Stream to Azure Event Hubs

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​

What this adapter does

For azure::1.0.0::eventhubs, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

​

How the latency targets were chosen

Small record append and iterator requests: +3 ms monthly p99 (adapter-added). GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations. Bounded record batch and read page: +10 ms monthly p99 (adapter-added). GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes. Stream configuration requests: +20 ms monthly p99 (adapter-added). CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, MergeShards, RegisterStreamConsumer, SplitShard, StartStreamEncryption, StopStreamEncryption, UpdateShardCount, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​

What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​

Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​

Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​

Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.

​

Example and diagnosis

For stream order-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​

Kinesis Data Stream to Managed Service for Apache Kafka

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​

What this adapter does

For google::1.0.0::managed-kafka, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

​

How the latency targets were chosen

Small record append and iterator requests: +3 ms monthly p99 (adapter-added). GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations. Bounded record batch and read page: +10 ms monthly p99 (adapter-added). GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes. Stream configuration requests: +20 ms monthly p99 (adapter-added). CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, MergeShards, RegisterStreamConsumer, SplitShard, StartStreamEncryption, StopStreamEncryption, UpdateShardCount, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​

What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​

Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​

Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​

Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.

​

Example and diagnosis

For stream order-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​

Kinesis Data Stream to Pub/Sub

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​

What this adapter does

For google::1.0.0::pubsub, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

​

How the latency targets were chosen

Small record append and iterator requests: +3 ms monthly p99 (adapter-added). GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations. Bounded record batch and read page: +10 ms monthly p99 (adapter-added). GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes. Stream configuration requests: +20 ms monthly p99 (adapter-added). CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, RegisterStreamConsumer, StartStreamEncryption, StopStreamEncryption, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​

What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​

Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​

Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​

Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.

​

Example and diagnosis

For stream order-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​

Kinesis Data Stream to OCI Streaming

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​

What this adapter does

For oci::1.0.0::streaming, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

​

How the latency targets were chosen

Small record append and iterator requests: +3 ms monthly p99 (adapter-added). GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations. Bounded record batch and read page: +10 ms monthly p99 (adapter-added). GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes. Stream configuration requests: +20 ms monthly p99 (adapter-added). CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, MergeShards, RegisterStreamConsumer, SplitShard, StartStreamEncryption, StopStreamEncryption, UpdateShardCount, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​

What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​

Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​

Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​

Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.

​

Example and diagnosis

For stream order-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​

Kinesis Data Stream to Strimzi Kafka

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​

What this adapter does

For strimzi::1.0.0::kafka, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

​

How the latency targets were chosen

Small record append and iterator requests: +3 ms monthly p99 (adapter-added). GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations. Bounded record batch and read page: +10 ms monthly p99 (adapter-added). GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes. Stream configuration requests: +20 ms monthly p99 (adapter-added). CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, MergeShards, RegisterStreamConsumer, SplitShard, StartStreamEncryption, StopStreamEncryption, UpdateShardCount, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​

What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​

Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​

Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​

Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.

​

Example and diagnosis

For stream order-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​

Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.