> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Kinesis Data Firehose > Kinesis Data Firehose APIs with Cloud Adapter. Preview This page describes how Kinesis Data Firehose maps to services in the environment where the application runs, including backend choices, supported operations and service-specific behavior. ## Supported environments * Akamai * Azure * DigitalOcean * Google Cloud * OCI * Private Kubernetes * Scaleway Check the operation and capability tables for the behavior your application depends on. A supported environment does not imply that every operation of the origin service is available. ## How the backends compare Each row compares a capability of Kinesis Data Firehose with its adaptation on each backend. A dash means this profile does not state the capability for that backend. ### Cloud Adapter | Capability | Kinesis Data Firehose | Akamai, DigitalOcean, Google Cloud, Private Kubernetes, and Scaleway · Strimzi Kafka | Azure | DigitalOcean · DigitalOcean Managed Kafka | Google Cloud · Pub/Sub | OCI | | - | - | - | - | - | - | - | | Ingest (Direct PUT) | PutRecord / PutRecordBatch | buffered onto Apache Kafka (Strimzi) on the target cluster | buffered onto Azure Event Hubs | buffered onto DigitalOcean Managed Kafka | buffered onto Google Cloud Pub/Sub | buffered onto OCI Streaming | | Record transformation · per-batch | Lambda | the Lambda equivalent | the Lambda equivalent | the Lambda equivalent | the Lambda equivalent | the Lambda equivalent | | Delivery sink · destination API | S3 / Redshift / OpenSearch / Snowflake / Splunk / Datadog / HTTP | Records are delivered through destination APIs; warehouse delivery is a record-loading integration, not a Redshift service replacement. | Records are delivered through destination APIs; warehouse delivery is a record-loading integration, not a Redshift service replacement. | Records are delivered through destination APIs; warehouse delivery is a record-loading integration, not a Redshift service replacement. | Records are delivered through destination APIs; warehouse delivery is a record-loading integration, not a Redshift service replacement. | Records are delivered through destination APIs; warehouse delivery is a record-loading integration, not a Redshift service replacement. | | Format conversion | Yes | Partial - JSON→Parquet served against a default/inferred schema; the declared Glue Data Catalog schema is AWS-specific and has no counterpart in the target cloud | Partial - JSON→Parquet served against a default/inferred schema; the declared Glue Data Catalog schema is AWS-specific and has no counterpart in the target cloud | Partial - JSON→Parquet served against a default/inferred schema; the declared Glue Data Catalog schema is AWS-specific and has no counterpart in the target cloud | Partial - JSON→Parquet served against a default/inferred schema; the declared Glue Data Catalog schema is AWS-specific and has no counterpart in the target cloud | Partial - JSON→Parquet served against a default/inferred schema; the declared Glue Data Catalog schema is AWS-specific and has no counterpart in the target cloud | | Snowflake / Splunk / Datadog sinks | Yes | Yes - delivered to Snowpipe / HEC / intake endpoints from the target cloud | Yes - delivered to Snowpipe / HEC / intake endpoints from the target cloud | Yes - delivered to Snowpipe / HEC / intake endpoints from the target cloud | Yes - delivered to Snowpipe / HEC / intake endpoints from the target cloud | Yes - delivered to Snowpipe / HEC / intake endpoints from the target cloud | | Redshift sink | Yes | Partial - A retained Redshift destination or a destination-specific warehouse loader; no database, schema or SQL migration | Partial - A retained Redshift destination or a destination-specific warehouse loader; no database, schema or SQL migration | Partial - A retained Redshift destination or a destination-specific warehouse loader; no database, schema or SQL migration | Partial - A retained Redshift destination or a destination-specific warehouse loader; no database, schema or SQL migration | Partial - A retained Redshift destination or a destination-specific warehouse loader; no database, schema or SQL migration | | API coverage | full | partial | partial | partial | partial | partial | ## On Akamai, DigitalOcean, Google Cloud, Private Kubernetes, and Scaleway ### Strimzi Kafka | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | Buffering (size / interval) | Delivery | Supported | Most usage | the buffer size and interval hints drive when a batch flushes to the sink | | Dynamic partitioning | Delivery | Partial | Full surface | key-based dynamic partitioning of the delivered objects is a subset of Firehose's grammar | | CreateDeliveryStream / DeleteDeliveryStream | Delivery stream | Supported | Common | the delivery stream, its buffering policy, and its sink are provisioned at apply-time | | PutRecord / PutRecordBatch (Direct PUT) | Ingest | Supported | Common | records are buffered onto Apache Kafka (Strimzi) on the target cluster; a Kinesis-stream source maps to the Kinesis adapter | | Delivery to destination APIs | Sink | Supported | Common | the delivery agent sends records to each configured destination through that service's API, preserving the destination's delivery behavior | | Sink: Apache Iceberg tables | Sink | Out of scope | Full surface | an Apache Iceberg destination is not offered: Iceberg tables register in the AWS Glue Data Catalog, which is AWS-specific and has no target-native counterpart on these backends | | Sink: OpenSearch Serverless | Sink | Partial | Full surface | the AWS serverless collection endpoint is replaced by the target cloud's OpenSearch or search service, using the same delivery mechanism as the OpenSearch destination | | Sink: Redshift (AWS warehouse) | Sink | Partial | Full surface | A retained Redshift destination requires a delivery integration. Moving record delivery to BigQuery, Synapse or ClickHouse requires a destination-specific object-storage load; it does not migrate Redshift schemas, SQL or warehouse behavior. | | Sink: S3 / object store, HTTP, OpenSearch | Sink | Supported | Common | the S3 sink bridges to the Cloud Adapter deployment object store (MinIO) (the target cloud's object store); an HTTP-endpoint sink forwards natively; an OpenSearch sink bridges to the target cloud's OpenSearch/Elasticsearch equivalent | | Sink: Snowflake / Splunk / Datadog (SaaS) | Sink | Supported | Most usage | records are sent to Snowflake Snowpipe, Splunk HTTP Event Collector (HEC), or Datadog's intake API. These endpoints can receive records from the target cloud | | Format conversion (JSON → Parquet) | Transform | Partial | Full surface | JSON→Parquet conversion uses a default or inferred schema. The declared AWS Glue Data Catalog schema is not translated, so conversion does not use your Glue table definition | | Record transformation (Lambda) | Transform | Supported | Most usage | a transform runs each batch through the Lambda equivalent before delivery | #### How it works Your application keeps sending `PutRecord` and `PutRecordBatch` requests, now to the Tensor9 adapter. The adapter buffers accepted records on Apache Kafka (Strimzi) on the target cluster, and a delivery worker sends batches to the destination, the Cloud Adapter deployment object store (MinIO). A successful call means the records were accepted into the buffer, not that the destination received them. When a batch has both successful and failed records, check each record's result. Size and interval settings decide when a batch is ready. A quiet stream may wait for the interval, and a busy one may reach the size first. Worker scheduling, optional transformation and the destination's response time also add delay, so the buffering interval is not an end-to-end latency guarantee. #### Transformation and destinations The intended delivery path can run a batch through the selected Lambda adapter before it is written. JSON-to-Parquet conversion uses a default or inferred schema, not the declared Glue table schema; check the field types and the resulting files with the tools that read them. HTTP, search and SaaS destinations need their own credentials, reachable endpoints and delivery formats. A warehouse destination delivers records to the selected warehouse; you configure its tables and load format. #### Limitations * **Glue table schemas for Parquet conversion are not supported.** Conversion uses a default or inferred schema. - **Moving a Redshift warehouse is not supported.** The database, schema, SQL queries and warehouse workload stay where they are. - **Retries behave differently: they can repeat records.** A destination can accept a batch before the worker records success, so a retry can repeat records or create a duplicate object. Downstream processing should detect duplicates. - **Buffered AWS records are not moved.** Records still buffered in the old AWS stream are not copied into the new buffer. #### Other considerations **Before switching producers.** Set up destination storage, credentials and any transformation first, and let the old AWS stream finish delivering its buffered records. Test the destination with representative batches, including failures and retries. **What to monitor.** Watch pending work, retry failures and destination delivery rather than successful `PutRecord` calls. Measure delivery delay and sustained throughput with your actual transform, batch settings and destination. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### Data Firehose · Billed ingestion Feature: Data Firehose. Estimated monthly service charges by Billed ingestion. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![Data Firehose · Billed ingestion: monthly service charges by Billed ingestion. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/0bb0373adae9ab1f313694289132a51d61ccbd5b236a05b10f0c516df1d5d6e1-light.svg) ![Data Firehose · Billed ingestion: monthly service charges by Billed ingestion. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/5cfbf7ce63ef37c4dec1f46f97c1a80065a9dcf1cca8860cf4cb24315a3b7b2d-dark.svg) 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. | Billed ingestion (GiB/month) | Kinesis Data Firehose | Target scenario | Strimzi Kafka | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Strimzi Kafka (one copy) | 80.90 | 80.90 | | 0 | 0.00 | Strimzi Kafka (two copies) | 161.79 | 161.79 | | 1 | 0.03 | Strimzi Kafka (one copy) | 80.90 | 80.87 | | 1 | 0.03 | Strimzi Kafka (two copies) | 161.80 | 161.77 | | 10 | 0.29 | Strimzi Kafka (one copy) | 80.94 | 80.65 | | 10 | 0.29 | Strimzi Kafka (two copies) | 161.84 | 161.55 | | 100 | 2.90 | Strimzi Kafka (one copy) | 81.37 | 78.47 | | 100 | 2.90 | Strimzi Kafka (two copies) | 162.27 | 159.37 | | 1,000 | 29.00 | Strimzi Kafka (one copy) | 85.64 | 56.64 | | 1,000 | 29.00 | Strimzi Kafka (two copies) | 166.53 | 137.53 | | 10,000 | 290.00 | Strimzi Kafka (one copy) | 128.31 | -161.69 | | 10,000 | 290.00 | Strimzi Kafka (two copies) | 209.21 | -80.79 | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Strimzi Kafka (one copy) | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Strimzi Kafka (one copy) | Representative record size | 1,024 | bytes | | Strimzi Kafka (one copy) | Output bytes / input bytes | 1 | fraction | | Strimzi Kafka (one copy) | Buffer residence | 60 | seconds | | Strimzi Kafka (one copy) | Staging metadata per record | 256 | bytes | | Strimzi Kafka (one copy) | Object sink retention | 30 | days | | Strimzi Kafka (one copy) | Output object size | 5 | MiB | | Strimzi Kafka (one copy) | Delivery worker CPU per record | 0.1 | vCPU-ms | | Strimzi Kafka (one copy) | Target price guess · read | 0 | USD/read | | Strimzi Kafka (one copy) | Target price guess · write | 0 | USD/write | | Strimzi Kafka (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Strimzi Kafka (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month | | Strimzi Kafka (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Strimzi Kafka (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Strimzi Kafka (one copy) | Target list price · network GiB | 0.12 | USD/network GiB | | Strimzi Kafka (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Strimzi Kafka (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Strimzi Kafka (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Strimzi Kafka (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Strimzi Kafka (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Strimzi Kafka (one copy) | Target price guess · input token | 0 | USD/input token | | Strimzi Kafka (one copy) | Target price guess · output token | 0 | USD/output token | | Strimzi Kafka (one copy) | Target monthly base charge | 0 | USD/month | | Strimzi Kafka (one copy) | Approximate target service minimum | 0 | USD/month | | Strimzi Kafka (one copy) | Minimum primary CPU | 2 | vCPU | | Strimzi Kafka (one copy) | Minimum primary RAM | 8 | GiB | | Strimzi Kafka (one copy) | Minimum primary disk | 100 | GiB | | Strimzi Kafka (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Strimzi Kafka (one copy) | Allocated share of provisioned cost | 1 | fraction | | Strimzi Kafka (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Strimzi Kafka (one copy) | Planning peak / mean work | 2 | multiplier | | Strimzi Kafka (one copy) | Planning primary CPU utilization | 0.5 | fraction | | Strimzi Kafka (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Strimzi Kafka (one copy) | Planning disk utilization | 0.8 | fraction | | Strimzi Kafka (one copy) | Maintenance and log disk reserve | 20 | GiB | | Strimzi Kafka (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Strimzi Kafka (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Strimzi Kafka (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Strimzi Kafka (one copy) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second | | Strimzi Kafka (one copy) | Broker replicas per written byte | 3 | replicas | | Strimzi Kafka (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Strimzi Kafka (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Strimzi Kafka (two copies) | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Strimzi Kafka (two copies) | Representative record size | 1,024 | bytes | | Strimzi Kafka (two copies) | Output bytes / input bytes | 1 | fraction | | Strimzi Kafka (two copies) | Buffer residence | 60 | seconds | | Strimzi Kafka (two copies) | Staging metadata per record | 256 | bytes | | Strimzi Kafka (two copies) | Object sink retention | 30 | days | | Strimzi Kafka (two copies) | Output object size | 5 | MiB | | Strimzi Kafka (two copies) | Delivery worker CPU per record | 0.1 | vCPU-ms | | Strimzi Kafka (two copies) | Target price guess · read | 0 | USD/read | | Strimzi Kafka (two copies) | Target price guess · write | 0 | USD/write | | Strimzi Kafka (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Strimzi Kafka (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month | | Strimzi Kafka (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Strimzi Kafka (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Strimzi Kafka (two copies) | Target list price · network GiB | 0.12 | USD/network GiB | | Strimzi Kafka (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Strimzi Kafka (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Strimzi Kafka (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Strimzi Kafka (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Strimzi Kafka (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Strimzi Kafka (two copies) | Target price guess · input token | 0 | USD/input token | | Strimzi Kafka (two copies) | Target price guess · output token | 0 | USD/output token | | Strimzi Kafka (two copies) | Target monthly base charge | 0 | USD/month | | Strimzi Kafka (two copies) | Approximate target service minimum | 0 | USD/month | | Strimzi Kafka (two copies) | Minimum primary CPU | 2 | vCPU | | Strimzi Kafka (two copies) | Minimum primary RAM | 8 | GiB | | Strimzi Kafka (two copies) | Minimum primary disk | 100 | GiB | | Strimzi Kafka (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Strimzi Kafka (two copies) | Allocated share of provisioned cost | 1 | fraction | | Strimzi Kafka (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Strimzi Kafka (two copies) | Planning peak / mean work | 2 | multiplier | | Strimzi Kafka (two copies) | Planning primary CPU utilization | 0.5 | fraction | | Strimzi Kafka (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Strimzi Kafka (two copies) | Planning disk utilization | 0.8 | fraction | | Strimzi Kafka (two copies) | Maintenance and log disk reserve | 20 | GiB | | Strimzi Kafka (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Strimzi Kafka (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Strimzi Kafka (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Strimzi Kafka (two copies) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second | | Strimzi Kafka (two copies) | Broker replicas per written byte | 3 | replicas | | Strimzi Kafka (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Strimzi Kafka (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Billed GiB includes per-record rounding; physical bytes can be much lower for small records. 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. * The landing buffer, durable staging, delivery workers and object sink are separate allocations. Primary stored GiB is retained landing payload; staging adds delivery metadata. * Object sink retention and PUTs are priced separately from the landing backend. Even an object-store landing target needs the explicitly modeled temporary buffer allocation. * These retention and sink-write assumptions are provisional; a broker-only subtotal does not price the complete pipeline. * Self-hosted target: Strimzi and Apache Kafka (Apache-2.0, [https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE](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](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](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](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, AmazonKinesisFirehose offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json) * Compute Engine general-purpose machine pricing: [https://cloud.google.com/products/compute/pricing/general-purpose](https://cloud.google.com/products/compute/pricing/general-purpose) * Disk and image pricing: [https://cloud.google.com/compute/disks-image-pricing](https://cloud.google.com/compute/disks-image-pricing) * Network pricing: [https://cloud.google.com/vpc/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. * Dynamic partitioning, format conversion, VPC delivery and origin sink charges; transformation-specific compute. * 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-6c87f4e94978e5b55e2f427442b2d980d92de89e` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonKinesisFirehose offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/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). **Data Firehose → 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. | Monthly component | USD | | - | -: | | Origin: Billed ingestion | 0.00 | | Target: Provisioned primary CPU | 46.15 | | Target: Provisioned primary RAM | 24.74 | | Target: Provisioned primary disk | 10.00 | | Target: Selected billable network | 0.00 | | Target: Independent provisioned resources | 0.00 | | Target: Independent managed resources | 0.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **80.90** | 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. * Dynamic partitioning, format conversion, VPC delivery and origin sink charges; transformation-specific compute. * 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** | Input | Value | Unit | | - | -: | - | | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Representative record size | 1,024 | bytes | | Output bytes / input bytes | 1 | fraction | | Buffer residence | 60 | seconds | | Staging metadata per record | 256 | bytes | | Object sink retention | 30 | days | | Output object size | 5 | MiB | | Delivery worker CPU per record | 0.1 | vCPU-ms | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.1 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target list price · network GiB | 0.12 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Approximate target service minimum | 0 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.5 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second | | Broker replicas per written byte | 3 | replicas | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Billed ingestion | 0 | GiB after5-KiB record rounding | * 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. * Explicit durable staging footprint: 0 GiB-month. * 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. * The landing buffer, durable staging, delivery workers and object sink are separate allocations. Primary stored GiB is retained landing payload; staging adds delivery metadata. * Object sink retention and PUTs are priced separately from the landing backend. Even an object-store landing target needs the explicitly modeled temporary buffer allocation. * These retention and sink-write assumptions are provisional; a broker-only subtotal does not price the complete pipeline. * Self-hosted target: Strimzi and Apache Kafka (Apache-2.0, [https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE](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](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](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](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-6c87f4e94978e5b55e2f427442b2d980d92de89e` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonKinesisFirehose offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/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). ## On Azure ### Azure Event Hubs | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | Buffering (size / interval) | Delivery | Supported | Most usage | the buffer size and interval hints drive when a batch flushes to the sink | | Dynamic partitioning | Delivery | Partial | Full surface | key-based dynamic partitioning of the delivered objects is a subset of Firehose's grammar | | CreateDeliveryStream / DeleteDeliveryStream | Delivery stream | Supported | Common | the delivery stream, its buffering policy, and its sink are provisioned at apply-time | | PutRecord / PutRecordBatch (Direct PUT) | Ingest | Supported | Common | records are buffered onto Azure Event Hubs; a Kinesis-stream source maps to the Kinesis adapter | | Delivery to destination APIs | Sink | Supported | Common | the delivery agent sends records to each configured destination through that service's API, preserving the destination's delivery behavior | | Sink: Apache Iceberg tables | Sink | Out of scope | Full surface | an Apache Iceberg destination is not offered: Iceberg tables register in the AWS Glue Data Catalog, which is AWS-specific and has no target-native counterpart on these backends | | Sink: OpenSearch Serverless | Sink | Partial | Full surface | the AWS serverless collection endpoint is replaced by the target cloud's OpenSearch or search service, using the same delivery mechanism as the OpenSearch destination | | Sink: Redshift (AWS warehouse) | Sink | Partial | Full surface | A retained Redshift destination requires a delivery integration. Moving record delivery to BigQuery, Synapse or ClickHouse requires a destination-specific object-storage load; it does not migrate Redshift schemas, SQL or warehouse behavior. | | Sink: S3 / object store, HTTP, OpenSearch | Sink | Supported | Common | the S3 sink bridges to Azure Blob Storage (the target cloud's object store); an HTTP-endpoint sink forwards natively; an OpenSearch sink bridges to the target cloud's OpenSearch/Elasticsearch equivalent | | Sink: Snowflake / Splunk / Datadog (SaaS) | Sink | Supported | Most usage | records are sent to Snowflake Snowpipe, Splunk HTTP Event Collector (HEC), or Datadog's intake API. These endpoints can receive records from the target cloud | | Format conversion (JSON → Parquet) | Transform | Partial | Full surface | JSON→Parquet conversion uses a default or inferred schema. The declared AWS Glue Data Catalog schema is not translated, so conversion does not use your Glue table definition | | Record transformation (Lambda) | Transform | Supported | Most usage | a transform runs each batch through the Lambda equivalent before delivery | #### How it works Your application keeps sending `PutRecord` and `PutRecordBatch` requests, now to the Tensor9 adapter. The adapter buffers accepted records on Azure Event Hubs, and a delivery worker sends batches to the destination, Azure Blob Storage. A successful call means the records were accepted into the buffer, not that the destination received them. When a batch has both successful and failed records, check each record's result. Size and interval settings decide when a batch is ready. A quiet stream may wait for the interval, and a busy one may reach the size first. Worker scheduling, optional transformation and the destination's response time also add delay, so the buffering interval is not an end-to-end latency guarantee. #### Transformation and destinations The intended delivery path can run a batch through the selected Lambda adapter before it is written. JSON-to-Parquet conversion uses a default or inferred schema, not the declared Glue table schema; check the field types and the resulting files with the tools that read them. HTTP, search and SaaS destinations need their own credentials, reachable endpoints and delivery formats. A warehouse destination delivers records to the selected warehouse; you configure its tables and load format. #### Limitations * **Glue table schemas for Parquet conversion are not supported.** Conversion uses a default or inferred schema. - **Moving a Redshift warehouse is not supported.** The database, schema, SQL queries and warehouse workload stay where they are. - **Retries behave differently: they can repeat records.** A destination can accept a batch before the worker records success, so a retry can repeat records or create a duplicate object. Downstream processing should detect duplicates. - **Buffered AWS records are not moved.** Records still buffered in the old AWS stream are not copied into the new buffer. #### Other considerations **Before switching producers.** Set up destination storage, credentials and any transformation first, and let the old AWS stream finish delivering its buffered records. Test the destination with representative batches, including failures and retries. **What to monitor.** Watch pending work, retry failures and destination delivery rather than successful `PutRecord` calls. Measure delivery delay and sustained throughput with your actual transform, batch settings and destination. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### Data Firehose · Billed ingestion Feature: Data Firehose. Estimated monthly service charges by Billed ingestion. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: East US; currency: USD. ![Data Firehose · Billed ingestion: monthly service charges by Billed ingestion. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/cb5659048a97457ebe63fe944a3972fc4b09a32aeb379bf7fc2fbbef48f8b8e9-light.svg) ![Data Firehose · Billed ingestion: monthly service charges by Billed ingestion. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/1ec578ad4906db7213d0d621589a439f3f29a05f874938dccd79f9b4d28a71b9-dark.svg) 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. | Billed ingestion (GiB/month) | Kinesis Data Firehose | Target scenario | Azure Event Hubs | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Azure Event Hubs (one staging copy) | 140.08 | 140.08 | | 0 | 0.00 | Azure Event Hubs (two staging copies) | 258.26 | 258.26 | | 1 | 0.03 | Azure Event Hubs (one staging copy) | 140.09 | 140.06 | | 1 | 0.03 | Azure Event Hubs (two staging copies) | 258.27 | 258.24 | | 10 | 0.29 | Azure Event Hubs (one staging copy) | 140.18 | 139.89 | | 10 | 0.29 | Azure Event Hubs (two staging copies) | 258.36 | 258.07 | | 100 | 2.90 | Azure Event Hubs (one staging copy) | 141.14 | 138.24 | | 100 | 2.90 | Azure Event Hubs (two staging copies) | 259.32 | 256.42 | | 1,000 | 29.00 | Azure Event Hubs (one staging copy) | 150.69 | 121.69 | | 1,000 | 29.00 | Azure Event Hubs (two staging copies) | 268.87 | 239.87 | | 10,000 | 290.00 | Azure Event Hubs (one staging copy) | 369.29 | 79.29 | | 10,000 | 290.00 | Azure Event Hubs (two staging copies) | 588.65 | 298.65 | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 GiB/month to 4 vCPU, 16 GiB memory and 100 GiB SSD at 10,000 GiB/month. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Azure Event Hubs (one staging copy) | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Azure Event Hubs (one staging copy) | Representative record size | 1,024 | bytes | | Azure Event Hubs (one staging copy) | Output bytes / input bytes | 1 | fraction | | Azure Event Hubs (one staging copy) | Buffer residence | 60 | seconds | | Azure Event Hubs (one staging copy) | Staging metadata per record | 256 | bytes | | Azure Event Hubs (one staging copy) | Object sink retention | 30 | days | | Azure Event Hubs (one staging copy) | Output object size | 5 | MiB | | Azure Event Hubs (one staging copy) | Delivery worker CPU per record | 0.1 | vCPU-ms | | Azure Event Hubs (one staging copy) | Target price guess · read | 0 | USD/read | | Azure Event Hubs (one staging copy) | Target list price · write | 0.000000028 | USD/write | | Azure Event Hubs (one staging copy) | Target price guess · provider operation | 0 | USD/provider operation | | Azure Event Hubs (one staging copy) | Target price guess · GiB-month | 0 | USD/GiB-month | | Azure Event Hubs (one staging copy) | Target price guess · published GiB | 0 | USD/published GiB | | Azure Event Hubs (one staging copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Azure Event Hubs (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB | | Azure Event Hubs (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Azure Event Hubs (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | Azure Event Hubs (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | Azure Event Hubs (one staging copy) | Target list price · resource-hour | 0.03 | USD/resource-hour | | Azure Event Hubs (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month | | Azure Event Hubs (one staging copy) | Target price guess · input token | 0 | USD/input token | | Azure Event Hubs (one staging copy) | Target price guess · output token | 0 | USD/output token | | Azure Event Hubs (one staging copy) | Target monthly base charge | 0 | USD/month | | Azure Event Hubs (one staging copy) | Approximate target service minimum | 0 | USD/month | | Azure Event Hubs (one staging copy) | Minimum primary CPU | 2 | vCPU | | Azure Event Hubs (one staging copy) | Minimum primary RAM | 8 | GiB | | Azure Event Hubs (one staging copy) | Minimum primary disk | 100 | GiB | | Azure Event Hubs (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 | | Azure Event Hubs (one staging copy) | Allocated share of provisioned cost | 1 | fraction | | Azure Event Hubs (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Azure Event Hubs (one staging copy) | Planning peak / mean work | 2 | multiplier | | Azure Event Hubs (one staging copy) | Planning primary CPU utilization | 0.7 | fraction | | Azure Event Hubs (one staging copy) | Resident state reserved in RAM | 0.1 | fraction | | Azure Event Hubs (one staging copy) | Planning disk utilization | 0.8 | fraction | | Azure Event Hubs (one staging copy) | Maintenance and log disk reserve | 20 | GiB | | Azure Event Hubs (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Azure Event Hubs (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Azure Event Hubs (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Azure Event Hubs (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Azure Event Hubs (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Azure Event Hubs (two staging copies) | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Azure Event Hubs (two staging copies) | Representative record size | 1,024 | bytes | | Azure Event Hubs (two staging copies) | Output bytes / input bytes | 1 | fraction | | Azure Event Hubs (two staging copies) | Buffer residence | 60 | seconds | | Azure Event Hubs (two staging copies) | Staging metadata per record | 256 | bytes | | Azure Event Hubs (two staging copies) | Object sink retention | 30 | days | | Azure Event Hubs (two staging copies) | Output object size | 5 | MiB | | Azure Event Hubs (two staging copies) | Delivery worker CPU per record | 0.1 | vCPU-ms | | Azure Event Hubs (two staging copies) | Target price guess · read | 0 | USD/read | | Azure Event Hubs (two staging copies) | Target list price · write | 0.000000028 | USD/write | | Azure Event Hubs (two staging copies) | Target price guess · provider operation | 0 | USD/provider operation | | Azure Event Hubs (two staging copies) | Target price guess · GiB-month | 0 | USD/GiB-month | | Azure Event Hubs (two staging copies) | Target price guess · published GiB | 0 | USD/published GiB | | Azure Event Hubs (two staging copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Azure Event Hubs (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB | | Azure Event Hubs (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Azure Event Hubs (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | Azure Event Hubs (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | Azure Event Hubs (two staging copies) | Target list price · resource-hour | 0.03 | USD/resource-hour | | Azure Event Hubs (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month | | Azure Event Hubs (two staging copies) | Target price guess · input token | 0 | USD/input token | | Azure Event Hubs (two staging copies) | Target price guess · output token | 0 | USD/output token | | Azure Event Hubs (two staging copies) | Target monthly base charge | 0 | USD/month | | Azure Event Hubs (two staging copies) | Approximate target service minimum | 0 | USD/month | | Azure Event Hubs (two staging copies) | Minimum primary CPU | 2 | vCPU | | Azure Event Hubs (two staging copies) | Minimum primary RAM | 8 | GiB | | Azure Event Hubs (two staging copies) | Minimum primary disk | 100 | GiB | | Azure Event Hubs (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 | | Azure Event Hubs (two staging copies) | Allocated share of provisioned cost | 1 | fraction | | Azure Event Hubs (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Azure Event Hubs (two staging copies) | Planning peak / mean work | 2 | multiplier | | Azure Event Hubs (two staging copies) | Planning primary CPU utilization | 0.7 | fraction | | Azure Event Hubs (two staging copies) | Resident state reserved in RAM | 0.1 | fraction | | Azure Event Hubs (two staging copies) | Planning disk utilization | 0.8 | fraction | | Azure Event Hubs (two staging copies) | Maintenance and log disk reserve | 20 | GiB | | Azure Event Hubs (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Azure Event Hubs (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Azure Event Hubs (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Azure Event Hubs (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Azure Event Hubs (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Billed GiB includes per-record rounding; physical bytes can be much lower for small records. 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. * The landing buffer, durable staging, delivery workers and object sink are separate allocations. Primary stored GiB is retained landing payload; staging adds delivery metadata. * Object sink retention and PUTs are priced separately from the landing backend. Even an object-store landing target needs the explicitly modeled temporary buffer allocation. * These retention and sink-write assumptions are provisional; a broker-only subtotal does not price the complete pipeline. * 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. * 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](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](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](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. * The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonKinesisFirehose offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json) * Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](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. * Dynamic partitioning, format conversion, VPC delivery and origin sink charges; transformation-specific compute. * 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-e70d3da9518fe5f10abaa57aa39c4824d78b4e6e` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonKinesisFirehose offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices). **Data Firehose → 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. | Monthly component | USD | | - | -: | | Origin: Billed ingestion | 0.00 | | Target: Target retained physical data | 0.00 | | Target: Additional broker replica storage | 0.00 | | Target: Target ingress events | 0.00 | | Target: Published bytes | 0.00 | | Target: Delivered bytes | 0.00 | | Target: Target native provider operations | 0.00 | | Target: Execution or worker CPU | 0.00 | | Target: Execution or worker RAM | 0.00 | | Target: Selected billable network | 0.00 | | Target: Independent native resources | 0.00 | | Target: throughput units at planning peak | 21.90 | | Target: Durable staging CPU | 60.30 | | Target: Durable staging RAM | 40.88 | | Target: Durable staging disk | 17.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **140.08** | 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. * Dynamic partitioning, format conversion, VPC delivery and origin sink charges; transformation-specific compute. * 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** | Input | Value | Unit | | - | -: | - | | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Representative record size | 1,024 | bytes | | Output bytes / input bytes | 1 | fraction | | Buffer residence | 60 | seconds | | Staging metadata per record | 256 | bytes | | Object sink retention | 30 | days | | Output object size | 5 | MiB | | Delivery worker CPU per record | 0.1 | vCPU-ms | | Target price guess · read | 0 | USD/read | | Target list price · write | 0.000000028 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target price guess · GiB-month | 0 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target price guess · network GiB | 0 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | Target price guess · GiB-hour | 0 | USD/GiB-hour | | Target list price · resource-hour | 0.03 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Approximate target service minimum | 0 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Billed ingestion | 0 | GiB after5-KiB record rounding | * 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. * Explicit durable staging footprint: 0 GiB-month. * 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. * The landing buffer, durable staging, delivery workers and object sink are separate allocations. Primary stored GiB is retained landing payload; staging adds delivery metadata. * Object sink retention and PUTs are priced separately from the landing backend. Even an object-store landing target needs the explicitly modeled temporary buffer allocation. * These retention and sink-write assumptions are provisional; a broker-only subtotal does not price the complete pipeline. * 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. * 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](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](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](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. * The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. List prices read: 2026-10-22. Model: `plan-e70d3da9518fe5f10abaa57aa39c4824d78b4e6e` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonKinesisFirehose offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices). ## On DigitalOcean ### DigitalOcean Managed Kafka | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | Buffering (size / interval) | Delivery | Supported | Most usage | the buffer size and interval hints drive when a batch flushes to the sink | | Dynamic partitioning | Delivery | Partial | Full surface | key-based dynamic partitioning of the delivered objects is a subset of Firehose's grammar | | CreateDeliveryStream / DeleteDeliveryStream | Delivery stream | Supported | Common | the delivery stream, its buffering policy, and its sink are provisioned at apply-time | | PutRecord / PutRecordBatch (Direct PUT) | Ingest | Supported | Common | records are buffered onto DigitalOcean Managed Kafka; a Kinesis-stream source maps to the Kinesis adapter | | Delivery to destination APIs | Sink | Supported | Common | the delivery agent sends records to each configured destination through that service's API, preserving the destination's delivery behavior | | Sink: Apache Iceberg tables | Sink | Out of scope | Full surface | an Apache Iceberg destination is not offered: Iceberg tables register in the AWS Glue Data Catalog, which is AWS-specific and has no target-native counterpart on these backends | | Sink: OpenSearch Serverless | Sink | Partial | Full surface | the AWS serverless collection endpoint is replaced by the target cloud's OpenSearch or search service, using the same delivery mechanism as the OpenSearch destination | | Sink: Redshift (AWS warehouse) | Sink | Partial | Full surface | A retained Redshift destination requires a delivery integration. Moving record delivery to BigQuery, Synapse or ClickHouse requires a destination-specific object-storage load; it does not migrate Redshift schemas, SQL or warehouse behavior. | | Sink: S3 / object store, HTTP, OpenSearch | Sink | Supported | Common | the S3 sink bridges to DigitalOcean Spaces (the target cloud's object store); an HTTP-endpoint sink forwards natively; an OpenSearch sink bridges to the target cloud's OpenSearch/Elasticsearch equivalent | | Sink: Snowflake / Splunk / Datadog (SaaS) | Sink | Supported | Most usage | records are sent to Snowflake Snowpipe, Splunk HTTP Event Collector (HEC), or Datadog's intake API. These endpoints can receive records from the target cloud | | Format conversion (JSON → Parquet) | Transform | Partial | Full surface | JSON→Parquet conversion uses a default or inferred schema. The declared AWS Glue Data Catalog schema is not translated, so conversion does not use your Glue table definition | | Record transformation (Lambda) | Transform | Supported | Most usage | a transform runs each batch through the Lambda equivalent before delivery | #### How it works Your application keeps sending `PutRecord` and `PutRecordBatch` requests, now to the Tensor9 adapter. The adapter buffers accepted records on DigitalOcean Managed Kafka, and a delivery worker sends batches to the destination, DigitalOcean Spaces. A successful call means the records were accepted into the buffer, not that the destination received them. When a batch has both successful and failed records, check each record's result. Size and interval settings decide when a batch is ready. A quiet stream may wait for the interval, and a busy one may reach the size first. Worker scheduling, optional transformation and the destination's response time also add delay, so the buffering interval is not an end-to-end latency guarantee. #### Transformation and destinations The intended delivery path can run a batch through the selected Lambda adapter before it is written. JSON-to-Parquet conversion uses a default or inferred schema, not the declared Glue table schema; check the field types and the resulting files with the tools that read them. HTTP, search and SaaS destinations need their own credentials, reachable endpoints and delivery formats. A warehouse destination delivers records to the selected warehouse; you configure its tables and load format. #### Limitations * **Glue table schemas for Parquet conversion are not supported.** Conversion uses a default or inferred schema. - **Moving a Redshift warehouse is not supported.** The database, schema, SQL queries and warehouse workload stay where they are. - **Retries behave differently: they can repeat records.** A destination can accept a batch before the worker records success, so a retry can repeat records or create a duplicate object. Downstream processing should detect duplicates. - **Buffered AWS records are not moved.** Records still buffered in the old AWS stream are not copied into the new buffer. #### Other considerations **Before switching producers.** Set up destination storage, credentials and any transformation first, and let the old AWS stream finish delivering its buffered records. Test the destination with representative batches, including failures and retries. **What to monitor.** Watch pending work, retry failures and destination delivery rather than successful `PutRecord` calls. Measure delivery delay and sustained throughput with your actual transform, batch settings and destination. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### Data Firehose · Billed ingestion Feature: Data Firehose. Estimated monthly service charges by Billed ingestion. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc (flat in every datacenter); currency: USD. ![Data Firehose · Billed ingestion: monthly service charges by Billed ingestion. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/3645c486087a934a1661614d906b7732f4f35017a4c3bb686dece86fe709cbb3-light.svg) ![Data Firehose · Billed ingestion: monthly service charges by Billed ingestion. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/0a4aaf7a669db58523bc4a6b21b6eb35559d3167858aeb11c252007ab0d4abd1-dark.svg) 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. | Billed ingestion (GiB/month) | Kinesis Data Firehose | Target scenario | DigitalOcean Managed Kafka | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | DigitalOcean Managed Kafka (one copy) | 198.40 | 198.40 | | 0 | 0.00 | DigitalOcean Managed Kafka (two copies) | 414.00 | 414.00 | | 1 | 0.03 | DigitalOcean Managed Kafka (one copy) | 198.40 | 198.38 | | 1 | 0.03 | DigitalOcean Managed Kafka (two copies) | 414.00 | 413.98 | | 10 | 0.29 | DigitalOcean Managed Kafka (one copy) | 198.45 | 198.16 | | 10 | 0.29 | DigitalOcean Managed Kafka (two copies) | 414.05 | 413.76 | | 100 | 2.90 | DigitalOcean Managed Kafka (one copy) | 198.87 | 195.97 | | 100 | 2.90 | DigitalOcean Managed Kafka (two copies) | 414.47 | 411.57 | | 1,000 | 29.00 | DigitalOcean Managed Kafka (one copy) | 203.14 | 174.14 | | 1,000 | 29.00 | DigitalOcean Managed Kafka (two copies) | 418.74 | 389.74 | | 10,000 | 290.00 | DigitalOcean Managed Kafka (one copy) | 245.82 | -44.18 | | 10,000 | 290.00 | DigitalOcean Managed Kafka (two copies) | 461.42 | 171.42 | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | DigitalOcean Managed Kafka (one copy) | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | DigitalOcean Managed Kafka (one copy) | Representative record size | 1,024 | bytes | | DigitalOcean Managed Kafka (one copy) | Output bytes / input bytes | 1 | fraction | | DigitalOcean Managed Kafka (one copy) | Buffer residence | 60 | seconds | | DigitalOcean Managed Kafka (one copy) | Staging metadata per record | 256 | bytes | | DigitalOcean Managed Kafka (one copy) | Object sink retention | 30 | days | | DigitalOcean Managed Kafka (one copy) | Output object size | 5 | MiB | | DigitalOcean Managed Kafka (one copy) | Delivery worker CPU per record | 0.1 | vCPU-ms | | DigitalOcean Managed Kafka (one copy) | Target price guess · read | 0 | USD/read | | DigitalOcean Managed Kafka (one copy) | Target price guess · write | 0 | USD/write | | DigitalOcean Managed Kafka (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | DigitalOcean Managed Kafka (one copy) | Target list price · GiB-month | 0.215 | USD/GiB-month | | DigitalOcean Managed Kafka (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | DigitalOcean Managed Kafka (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | DigitalOcean Managed Kafka (one copy) | Target price guess · network GiB | 0 | USD/network GiB | | DigitalOcean Managed Kafka (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | DigitalOcean Managed Kafka (one copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | DigitalOcean Managed Kafka (one copy) | Target list price · GiB-hour | 0.0339726 | USD/GiB-hour | | DigitalOcean Managed Kafka (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | DigitalOcean Managed Kafka (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | DigitalOcean Managed Kafka (one copy) | Target price guess · input token | 0 | USD/input token | | DigitalOcean Managed Kafka (one copy) | Target price guess · output token | 0 | USD/output token | | DigitalOcean Managed Kafka (one copy) | Included before billing · GiB-month | 120 | GiB-month | | DigitalOcean Managed Kafka (one copy) | Target monthly base charge | 0 | USD/month | | DigitalOcean Managed Kafka (one copy) | Target service minimum | 148.8 | USD/month | | DigitalOcean Managed Kafka (one copy) | Minimum primary CPU | 2 | vCPU | | DigitalOcean Managed Kafka (one copy) | Minimum primary RAM | 8 | GiB | | DigitalOcean Managed Kafka (one copy) | Minimum primary disk | 100 | GiB | | DigitalOcean Managed Kafka (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | DigitalOcean Managed Kafka (one copy) | Allocated share of provisioned cost | 1 | fraction | | DigitalOcean Managed Kafka (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | DigitalOcean Managed Kafka (one copy) | Planning peak / mean work | 2 | multiplier | | DigitalOcean Managed Kafka (one copy) | Planning primary CPU utilization | 0.5 | fraction | | DigitalOcean Managed Kafka (one copy) | Resident state reserved in RAM | 0.1 | fraction | | DigitalOcean Managed Kafka (one copy) | Planning disk utilization | 0.8 | fraction | | DigitalOcean Managed Kafka (one copy) | Maintenance and log disk reserve | 20 | GiB | | DigitalOcean Managed Kafka (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | DigitalOcean Managed Kafka (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | DigitalOcean Managed Kafka (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | DigitalOcean Managed Kafka (one copy) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second | | DigitalOcean Managed Kafka (one copy) | Broker replicas per written byte | 3 | replicas | | DigitalOcean Managed Kafka (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | DigitalOcean Managed Kafka (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | DigitalOcean Managed Kafka (two copies) | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | DigitalOcean Managed Kafka (two copies) | Representative record size | 1,024 | bytes | | DigitalOcean Managed Kafka (two copies) | Output bytes / input bytes | 1 | fraction | | DigitalOcean Managed Kafka (two copies) | Buffer residence | 60 | seconds | | DigitalOcean Managed Kafka (two copies) | Staging metadata per record | 256 | bytes | | DigitalOcean Managed Kafka (two copies) | Object sink retention | 30 | days | | DigitalOcean Managed Kafka (two copies) | Output object size | 5 | MiB | | DigitalOcean Managed Kafka (two copies) | Delivery worker CPU per record | 0.1 | vCPU-ms | | DigitalOcean Managed Kafka (two copies) | Target price guess · read | 0 | USD/read | | DigitalOcean Managed Kafka (two copies) | Target price guess · write | 0 | USD/write | | DigitalOcean Managed Kafka (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | DigitalOcean Managed Kafka (two copies) | Target list price · GiB-month | 0.215 | USD/GiB-month | | DigitalOcean Managed Kafka (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | DigitalOcean Managed Kafka (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | DigitalOcean Managed Kafka (two copies) | Target price guess · network GiB | 0 | USD/network GiB | | DigitalOcean Managed Kafka (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | DigitalOcean Managed Kafka (two copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | DigitalOcean Managed Kafka (two copies) | Target list price · GiB-hour | 0.0339726 | USD/GiB-hour | | DigitalOcean Managed Kafka (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | DigitalOcean Managed Kafka (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | DigitalOcean Managed Kafka (two copies) | Target price guess · input token | 0 | USD/input token | | DigitalOcean Managed Kafka (two copies) | Target price guess · output token | 0 | USD/output token | | DigitalOcean Managed Kafka (two copies) | Included before billing · GiB-month | 120 | GiB-month | | DigitalOcean Managed Kafka (two copies) | Target monthly base charge | 0 | USD/month | | DigitalOcean Managed Kafka (two copies) | Target service minimum | 148.8 | USD/month | | DigitalOcean Managed Kafka (two copies) | Minimum primary CPU | 2 | vCPU | | DigitalOcean Managed Kafka (two copies) | Minimum primary RAM | 8 | GiB | | DigitalOcean Managed Kafka (two copies) | Minimum primary disk | 100 | GiB | | DigitalOcean Managed Kafka (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | DigitalOcean Managed Kafka (two copies) | Allocated share of provisioned cost | 1 | fraction | | DigitalOcean Managed Kafka (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | DigitalOcean Managed Kafka (two copies) | Planning peak / mean work | 2 | multiplier | | DigitalOcean Managed Kafka (two copies) | Planning primary CPU utilization | 0.5 | fraction | | DigitalOcean Managed Kafka (two copies) | Resident state reserved in RAM | 0.1 | fraction | | DigitalOcean Managed Kafka (two copies) | Planning disk utilization | 0.8 | fraction | | DigitalOcean Managed Kafka (two copies) | Maintenance and log disk reserve | 20 | GiB | | DigitalOcean Managed Kafka (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | DigitalOcean Managed Kafka (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | DigitalOcean Managed Kafka (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | DigitalOcean Managed Kafka (two copies) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second | | DigitalOcean Managed Kafka (two copies) | Broker replicas per written byte | 3 | replicas | | DigitalOcean Managed Kafka (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | DigitalOcean Managed Kafka (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Billed GiB includes per-record rounding; physical bytes can be much lower for small records. 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 → nyc (flat in every datacenter), 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. * The landing buffer, durable staging, delivery workers and object sink are separate allocations. Primary stored GiB is retained landing payload; staging adds delivery metadata. * Object sink retention and PUTs are priced separately from the landing backend. Even an object-store landing target needs the explicitly modeled temporary buffer allocation. * These retention and sink-write assumptions are provisional; a broker-only subtotal does not price the complete pipeline. * DigitalOcean Managed Kafka bills fixed three-broker plans with CPU included and a minimum storage allocation, plus extra storage. The smallest plan (6 GiB of cluster RAM, 120-240 GiB storage) is USD 148.80/month and the next (12 GiB) USD 296.25, about USD 24.80 per GiB of cluster RAM a month, so the model bills the selected RAM at that rate with no CPU charge, without rounding to a plan or to multiples of three nodes. The three brokers already replicate, so a selected standby copy overstates the cluster. Storage above the plan's included 120 GiB bills USD 0.215 per GiB-month in 30 GiB increments. DigitalOcean's documentation page (last verified 17 June 2025) still lists the older USD 147.00 plan. * 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](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](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](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, AmazonKinesisFirehose offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json) * DigitalOcean Managed Databases pricing: [https://www.digitalocean.com/pricing/managed-databases](https://www.digitalocean.com/pricing/managed-databases) 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. * Dynamic partitioning, format conversion, VPC delivery and origin sink charges; transformation-specific compute. * 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-8e2479a9662ef15033310a5a989b2e07fdda1c17` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonKinesisFirehose offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases). **Data Firehose → DigitalOcean Managed 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: nyc (flat in every datacenter). Currency: USD. | Monthly component | USD | | - | -: | | Origin: Billed ingestion | 0.00 | | Target: Provisioned primary CPU | 0.00 | | Target: Provisioned primary RAM | 198.40 | | Target: Provisioned primary disk after 120 included | 0.00 | | Target: Selected billable network | 0.00 | | Target: Independent provisioned resources | 0.00 | | Target: Independent managed resources | 0.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **198.40** | 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. * Dynamic partitioning, format conversion, VPC delivery and origin sink charges; transformation-specific compute. * 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** | Input | Value | Unit | | - | -: | - | | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Representative record size | 1,024 | bytes | | Output bytes / input bytes | 1 | fraction | | Buffer residence | 60 | seconds | | Staging metadata per record | 256 | bytes | | Object sink retention | 30 | days | | Output object size | 5 | MiB | | Delivery worker CPU per record | 0.1 | vCPU-ms | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.215 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target price guess · network GiB | 0 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | Target list price · GiB-hour | 0.0339726 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Included before billing · GiB-month | 120 | GiB-month | | Target monthly base charge | 0 | USD/month | | Target service minimum | 148.8 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.5 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second | | Broker replicas per written byte | 3 | replicas | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Billed ingestion | 0 | GiB after5-KiB record rounding | * 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. * Explicit durable staging footprint: 0 GiB-month. * 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. * The landing buffer, durable staging, delivery workers and object sink are separate allocations. Primary stored GiB is retained landing payload; staging adds delivery metadata. * Object sink retention and PUTs are priced separately from the landing backend. Even an object-store landing target needs the explicitly modeled temporary buffer allocation. * These retention and sink-write assumptions are provisional; a broker-only subtotal does not price the complete pipeline. * DigitalOcean Managed Kafka bills fixed three-broker plans with CPU included and a minimum storage allocation, plus extra storage. The smallest plan (6 GiB of cluster RAM, 120-240 GiB storage) is USD 148.80/month and the next (12 GiB) USD 296.25, about USD 24.80 per GiB of cluster RAM a month, so the model bills the selected RAM at that rate with no CPU charge, without rounding to a plan or to multiples of three nodes. The three brokers already replicate, so a selected standby copy overstates the cluster. Storage above the plan's included 120 GiB bills USD 0.215 per GiB-month in 30 GiB increments. DigitalOcean's documentation page (last verified 17 June 2025) still lists the older USD 147.00 plan. * 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](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](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](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-8e2479a9662ef15033310a5a989b2e07fdda1c17` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonKinesisFirehose offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases). ## On Google Cloud ### Pub/Sub | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | Buffering (size / interval) | Delivery | Supported | Most usage | the buffer size and interval hints drive when a batch flushes to the sink | | Dynamic partitioning | Delivery | Partial | Full surface | key-based dynamic partitioning of the delivered objects is a subset of Firehose's grammar | | CreateDeliveryStream / DeleteDeliveryStream | Delivery stream | Supported | Common | the delivery stream, its buffering policy, and its sink are provisioned at apply-time | | PutRecord / PutRecordBatch (Direct PUT) | Ingest | Supported | Common | records are buffered onto Google Cloud Pub/Sub; a Kinesis-stream source maps to the Kinesis adapter | | Delivery to destination APIs | Sink | Supported | Common | the delivery agent sends records to each configured destination through that service's API, preserving the destination's delivery behavior | | Sink: Apache Iceberg tables | Sink | Out of scope | Full surface | an Apache Iceberg destination is not offered: Iceberg tables register in the AWS Glue Data Catalog, which is AWS-specific and has no target-native counterpart on these backends | | Sink: OpenSearch Serverless | Sink | Partial | Full surface | the AWS serverless collection endpoint is replaced by the target cloud's OpenSearch or search service, using the same delivery mechanism as the OpenSearch destination | | Sink: Redshift (AWS warehouse) | Sink | Partial | Full surface | A retained Redshift destination requires a delivery integration. Moving record delivery to BigQuery, Synapse or ClickHouse requires a destination-specific object-storage load; it does not migrate Redshift schemas, SQL or warehouse behavior. | | Sink: S3 / object store, HTTP, OpenSearch | Sink | Supported | Common | the S3 sink bridges to Google Cloud Storage (the target cloud's object store); an HTTP-endpoint sink forwards natively; an OpenSearch sink bridges to the target cloud's OpenSearch/Elasticsearch equivalent | | Sink: Snowflake / Splunk / Datadog (SaaS) | Sink | Supported | Most usage | records are sent to Snowflake Snowpipe, Splunk HTTP Event Collector (HEC), or Datadog's intake API. These endpoints can receive records from the target cloud | | Format conversion (JSON → Parquet) | Transform | Partial | Full surface | JSON→Parquet conversion uses a default or inferred schema. The declared AWS Glue Data Catalog schema is not translated, so conversion does not use your Glue table definition | | Record transformation (Lambda) | Transform | Supported | Most usage | a transform runs each batch through the Lambda equivalent before delivery | #### How it works Your application keeps sending `PutRecord` and `PutRecordBatch` requests, now to the Tensor9 adapter. The adapter buffers accepted records on Google Cloud Pub/Sub, and a delivery worker sends batches to the destination, Google Cloud Storage. A successful call means the records were accepted into the buffer, not that the destination received them. When a batch has both successful and failed records, check each record's result. Size and interval settings decide when a batch is ready. A quiet stream may wait for the interval, and a busy one may reach the size first. Worker scheduling, optional transformation and the destination's response time also add delay, so the buffering interval is not an end-to-end latency guarantee. #### Transformation and destinations The intended delivery path can run a batch through the selected Lambda adapter before it is written. JSON-to-Parquet conversion uses a default or inferred schema, not the declared Glue table schema; check the field types and the resulting files with the tools that read them. HTTP, search and SaaS destinations need their own credentials, reachable endpoints and delivery formats. A warehouse destination delivers records to the selected warehouse; you configure its tables and load format. #### Limitations * **Glue table schemas for Parquet conversion are not supported.** Conversion uses a default or inferred schema. - **Moving a Redshift warehouse is not supported.** The database, schema, SQL queries and warehouse workload stay where they are. - **Retries behave differently: they can repeat records.** A destination can accept a batch before the worker records success, so a retry can repeat records or create a duplicate object. Downstream processing should detect duplicates. - **Buffered AWS records are not moved.** Records still buffered in the old AWS stream are not copied into the new buffer. #### Other considerations **Before switching producers.** Set up destination storage, credentials and any transformation first, and let the old AWS stream finish delivering its buffered records. Test the destination with representative batches, including failures and retries. **What to monitor.** Watch pending work, retry failures and destination delivery rather than successful `PutRecord` calls. Measure delivery delay and sustained throughput with your actual transform, batch settings and destination. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### Data Firehose · Billed ingestion Feature: Data Firehose. Estimated monthly service charges by Billed ingestion. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![Data Firehose · Billed ingestion: monthly service charges by Billed ingestion. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/916ee9615c4d198ecab98fb7bc6c61b2ac2165c41132deda57cbbbe17097d93d-light.svg) ![Data Firehose · Billed ingestion: monthly service charges by Billed ingestion. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/4406c5bcb36488e5cbf5c5efbb270a8f71ccc937ae213a221e998a0e35ebc793-dark.svg) 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. | Billed ingestion (GiB/month) | Kinesis Data Firehose | Target scenario | Pub/Sub | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Pub/Sub (one staging copy) | 118.18 | 118.18 | | 0 | 0.00 | Pub/Sub (two staging copies) | 236.36 | 236.36 | | 1 | 0.03 | Pub/Sub (one staging copy) | 118.20 | 118.17 | | 1 | 0.03 | Pub/Sub (two staging copies) | 236.38 | 236.35 | | 10 | 0.29 | Pub/Sub (one staging copy) | 118.38 | 118.09 | | 10 | 0.29 | Pub/Sub (two staging copies) | 236.56 | 236.27 | | 100 | 2.90 | Pub/Sub (one staging copy) | 120.21 | 117.31 | | 100 | 2.90 | Pub/Sub (two staging copies) | 238.39 | 235.49 | | 1,000 | 29.00 | Pub/Sub (one staging copy) | 138.55 | 109.55 | | 1,000 | 29.00 | Pub/Sub (two staging copies) | 256.72 | 227.72 | | 10,000 | 290.00 | Pub/Sub (one staging copy) | 423.04 | 133.04 | | 10,000 | 290.00 | Pub/Sub (two staging copies) | 642.39 | 352.39 | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 GiB/month to 4 vCPU, 16 GiB memory and 100 GiB SSD at 10,000 GiB/month. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Pub/Sub (one staging copy) | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Pub/Sub (one staging copy) | Representative record size | 1,024 | bytes | | Pub/Sub (one staging copy) | Output bytes / input bytes | 1 | fraction | | Pub/Sub (one staging copy) | Buffer residence | 60 | seconds | | Pub/Sub (one staging copy) | Staging metadata per record | 256 | bytes | | Pub/Sub (one staging copy) | Object sink retention | 30 | days | | Pub/Sub (one staging copy) | Output object size | 5 | MiB | | Pub/Sub (one staging copy) | Delivery worker CPU per record | 0.1 | vCPU-ms | | Pub/Sub (one staging copy) | Target price guess · read | 0 | USD/read | | Pub/Sub (one staging copy) | Target price guess · write | 0 | USD/write | | Pub/Sub (one staging copy) | Target price guess · provider operation | 0 | USD/provider operation | | Pub/Sub (one staging copy) | Target list price · GiB-month | 0.27 | USD/GiB-month | | Pub/Sub (one staging copy) | Target list price · published GiB | 0.0390625 | USD/published GiB | | Pub/Sub (one staging copy) | Target list price · delivered GiB | 0.0390625 | USD/delivered GiB | | Pub/Sub (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB | | Pub/Sub (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Pub/Sub (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | Pub/Sub (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | Pub/Sub (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Pub/Sub (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month | | Pub/Sub (one staging copy) | Target price guess · input token | 0 | USD/input token | | Pub/Sub (one staging copy) | Target price guess · output token | 0 | USD/output token | | Pub/Sub (one staging copy) | Target monthly base charge | 0 | USD/month | | Pub/Sub (one staging copy) | Approximate target service minimum | 0 | USD/month | | Pub/Sub (one staging copy) | Minimum primary CPU | 2 | vCPU | | Pub/Sub (one staging copy) | Minimum primary RAM | 8 | GiB | | Pub/Sub (one staging copy) | Minimum primary disk | 100 | GiB | | Pub/Sub (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 | | Pub/Sub (one staging copy) | Allocated share of provisioned cost | 1 | fraction | | Pub/Sub (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Pub/Sub (one staging copy) | Planning peak / mean work | 2 | multiplier | | Pub/Sub (one staging copy) | Planning primary CPU utilization | 0.7 | fraction | | Pub/Sub (one staging copy) | Resident state reserved in RAM | 0.1 | fraction | | Pub/Sub (one staging copy) | Planning disk utilization | 0.8 | fraction | | Pub/Sub (one staging copy) | Maintenance and log disk reserve | 20 | GiB | | Pub/Sub (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Pub/Sub (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Pub/Sub (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Pub/Sub (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Pub/Sub (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Pub/Sub (two staging copies) | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Pub/Sub (two staging copies) | Representative record size | 1,024 | bytes | | Pub/Sub (two staging copies) | Output bytes / input bytes | 1 | fraction | | Pub/Sub (two staging copies) | Buffer residence | 60 | seconds | | Pub/Sub (two staging copies) | Staging metadata per record | 256 | bytes | | Pub/Sub (two staging copies) | Object sink retention | 30 | days | | Pub/Sub (two staging copies) | Output object size | 5 | MiB | | Pub/Sub (two staging copies) | Delivery worker CPU per record | 0.1 | vCPU-ms | | Pub/Sub (two staging copies) | Target price guess · read | 0 | USD/read | | Pub/Sub (two staging copies) | Target price guess · write | 0 | USD/write | | Pub/Sub (two staging copies) | Target price guess · provider operation | 0 | USD/provider operation | | Pub/Sub (two staging copies) | Target list price · GiB-month | 0.27 | USD/GiB-month | | Pub/Sub (two staging copies) | Target list price · published GiB | 0.0390625 | USD/published GiB | | Pub/Sub (two staging copies) | Target list price · delivered GiB | 0.0390625 | USD/delivered GiB | | Pub/Sub (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB | | Pub/Sub (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Pub/Sub (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | Pub/Sub (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | Pub/Sub (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Pub/Sub (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month | | Pub/Sub (two staging copies) | Target price guess · input token | 0 | USD/input token | | Pub/Sub (two staging copies) | Target price guess · output token | 0 | USD/output token | | Pub/Sub (two staging copies) | Target monthly base charge | 0 | USD/month | | Pub/Sub (two staging copies) | Approximate target service minimum | 0 | USD/month | | Pub/Sub (two staging copies) | Minimum primary CPU | 2 | vCPU | | Pub/Sub (two staging copies) | Minimum primary RAM | 8 | GiB | | Pub/Sub (two staging copies) | Minimum primary disk | 100 | GiB | | Pub/Sub (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 | | Pub/Sub (two staging copies) | Allocated share of provisioned cost | 1 | fraction | | Pub/Sub (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Pub/Sub (two staging copies) | Planning peak / mean work | 2 | multiplier | | Pub/Sub (two staging copies) | Planning primary CPU utilization | 0.7 | fraction | | Pub/Sub (two staging copies) | Resident state reserved in RAM | 0.1 | fraction | | Pub/Sub (two staging copies) | Planning disk utilization | 0.8 | fraction | | Pub/Sub (two staging copies) | Maintenance and log disk reserve | 20 | GiB | | Pub/Sub (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Pub/Sub (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Pub/Sub (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Pub/Sub (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Pub/Sub (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Billed GiB includes per-record rounding; physical bytes can be much lower for small records. 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. * The landing buffer, durable staging, delivery workers and object sink are separate allocations. Primary stored GiB is retained landing payload; staging adds delivery metadata. * Object sink retention and PUTs are priced separately from the landing backend. Even an object-store landing target needs the explicitly modeled temporary buffer allocation. * These retention and sink-write assumptions are provisional; a broker-only subtotal does not price the complete pipeline. * Google Pub/Sub bills published and delivered bytes at the Message Delivery Basic rate and retained messages per GiB-month. Each request is billed at no less than 1,000 bytes; the family's batching and delivery assumptions must represent that. The first 10 GiB of combined throughput a month is free per billing account and is not applied. BigQuery and Cloud Storage subscriptions bill USD 50 per TiB instead. Unacknowledged messages younger than one day bill no storage. * 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](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](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](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. * The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonKinesisFirehose offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json) * Pub/Sub pricing: [https://cloud.google.com/pubsub/pricing](https://cloud.google.com/pubsub/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. * Dynamic partitioning, format conversion, VPC delivery and origin sink charges; transformation-specific compute. * 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-8e313c75fd8bde1c00ef6902b0b9b1fc60233239` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonKinesisFirehose offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json), [Pub/Sub pricing](https://cloud.google.com/pubsub/pricing). **Data Firehose → Pub/Sub: 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. | Monthly component | USD | | - | -: | | Origin: Billed ingestion | 0.00 | | Target: Target retained physical data | 0.00 | | Target: Additional broker replica storage | 0.00 | | Target: Target ingress events | 0.00 | | Target: Published bytes | 0.00 | | Target: Delivered bytes | 0.00 | | Target: Target native provider operations | 0.00 | | Target: Execution or worker CPU | 0.00 | | Target: Execution or worker RAM | 0.00 | | Target: Selected billable network | 0.00 | | Target: Independent native resources | 0.00 | | Target: Independent native resources | 0.00 | | Target: Durable staging CPU | 60.30 | | Target: Durable staging RAM | 40.88 | | Target: Durable staging disk | 17.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **118.18** | 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. * Dynamic partitioning, format conversion, VPC delivery and origin sink charges; transformation-specific compute. * 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** | Input | Value | Unit | | - | -: | - | | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Representative record size | 1,024 | bytes | | Output bytes / input bytes | 1 | fraction | | Buffer residence | 60 | seconds | | Staging metadata per record | 256 | bytes | | Object sink retention | 30 | days | | Output object size | 5 | MiB | | Delivery worker CPU per record | 0.1 | vCPU-ms | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.27 | USD/GiB-month | | Target list price · published GiB | 0.0390625 | USD/published GiB | | Target list price · delivered GiB | 0.0390625 | USD/delivered GiB | | Target price guess · network GiB | 0 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | Target price guess · GiB-hour | 0 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Approximate target service minimum | 0 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Billed ingestion | 0 | GiB after5-KiB record rounding | * 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. * Explicit durable staging footprint: 0 GiB-month. * 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. * The landing buffer, durable staging, delivery workers and object sink are separate allocations. Primary stored GiB is retained landing payload; staging adds delivery metadata. * Object sink retention and PUTs are priced separately from the landing backend. Even an object-store landing target needs the explicitly modeled temporary buffer allocation. * These retention and sink-write assumptions are provisional; a broker-only subtotal does not price the complete pipeline. * Google Pub/Sub bills published and delivered bytes at the Message Delivery Basic rate and retained messages per GiB-month. Each request is billed at no less than 1,000 bytes; the family's batching and delivery assumptions must represent that. The first 10 GiB of combined throughput a month is free per billing account and is not applied. BigQuery and Cloud Storage subscriptions bill USD 50 per TiB instead. Unacknowledged messages younger than one day bill no storage. * 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](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](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](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. * The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. List prices read: 2026-10-22. Model: `plan-8e313c75fd8bde1c00ef6902b0b9b1fc60233239` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonKinesisFirehose offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json), [Pub/Sub pricing](https://cloud.google.com/pubsub/pricing). ## On OCI ### OCI Streaming | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | Buffering (size / interval) | Delivery | Supported | Most usage | the buffer size and interval hints drive when a batch flushes to the sink | | Dynamic partitioning | Delivery | Partial | Full surface | key-based dynamic partitioning of the delivered objects is a subset of Firehose's grammar | | CreateDeliveryStream / DeleteDeliveryStream | Delivery stream | Supported | Common | the delivery stream, its buffering policy, and its sink are provisioned at apply-time | | PutRecord / PutRecordBatch (Direct PUT) | Ingest | Supported | Common | records are buffered onto OCI Streaming; a Kinesis-stream source maps to the Kinesis adapter | | Delivery to destination APIs | Sink | Supported | Common | the delivery agent sends records to each configured destination through that service's API, preserving the destination's delivery behavior | | Sink: Apache Iceberg tables | Sink | Out of scope | Full surface | an Apache Iceberg destination is not offered: Iceberg tables register in the AWS Glue Data Catalog, which is AWS-specific and has no target-native counterpart on these backends | | Sink: OpenSearch Serverless | Sink | Partial | Full surface | the AWS serverless collection endpoint is replaced by the target cloud's OpenSearch or search service, using the same delivery mechanism as the OpenSearch destination | | Sink: Redshift (AWS warehouse) | Sink | Partial | Full surface | A retained Redshift destination requires a delivery integration. Moving record delivery to BigQuery, Synapse or ClickHouse requires a destination-specific object-storage load; it does not migrate Redshift schemas, SQL or warehouse behavior. | | Sink: S3 / object store, HTTP, OpenSearch | Sink | Supported | Common | the S3 sink bridges to OCI Object Storage (the target cloud's object store); an HTTP-endpoint sink forwards natively; an OpenSearch sink bridges to the target cloud's OpenSearch/Elasticsearch equivalent | | Sink: Snowflake / Splunk / Datadog (SaaS) | Sink | Supported | Most usage | records are sent to Snowflake Snowpipe, Splunk HTTP Event Collector (HEC), or Datadog's intake API. These endpoints can receive records from the target cloud | | Format conversion (JSON → Parquet) | Transform | Partial | Full surface | JSON→Parquet conversion uses a default or inferred schema. The declared AWS Glue Data Catalog schema is not translated, so conversion does not use your Glue table definition | | Record transformation (Lambda) | Transform | Supported | Most usage | a transform runs each batch through the Lambda equivalent before delivery | #### How it works Your application keeps sending `PutRecord` and `PutRecordBatch` requests, now to the Tensor9 adapter. The adapter buffers accepted records on OCI Streaming, and a delivery worker sends batches to the destination, OCI Object Storage. A successful call means the records were accepted into the buffer, not that the destination received them. When a batch has both successful and failed records, check each record's result. Size and interval settings decide when a batch is ready. A quiet stream may wait for the interval, and a busy one may reach the size first. Worker scheduling, optional transformation and the destination's response time also add delay, so the buffering interval is not an end-to-end latency guarantee. #### Transformation and destinations The intended delivery path can run a batch through the selected Lambda adapter before it is written. JSON-to-Parquet conversion uses a default or inferred schema, not the declared Glue table schema; check the field types and the resulting files with the tools that read them. HTTP, search and SaaS destinations need their own credentials, reachable endpoints and delivery formats. A warehouse destination delivers records to the selected warehouse; you configure its tables and load format. #### Limitations * **Glue table schemas for Parquet conversion are not supported.** Conversion uses a default or inferred schema. - **Moving a Redshift warehouse is not supported.** The database, schema, SQL queries and warehouse workload stay where they are. - **Retries behave differently: they can repeat records.** A destination can accept a batch before the worker records success, so a retry can repeat records or create a duplicate object. Downstream processing should detect duplicates. - **Buffered AWS records are not moved.** Records still buffered in the old AWS stream are not copied into the new buffer. #### Other considerations **Before switching producers.** Set up destination storage, credentials and any transformation first, and let the old AWS stream finish delivering its buffered records. Test the destination with representative batches, including failures and retries. **What to monitor.** Watch pending work, retry failures and destination delivery rather than successful `PutRecord` calls. Measure delivery delay and sustained throughput with your actual transform, batch settings and destination. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### Data Firehose · Billed ingestion Feature: Data Firehose. Estimated monthly service charges by Billed ingestion. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (OCI global price list); currency: USD. ![Data Firehose · Billed ingestion: monthly service charges by Billed ingestion. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/d5cb276d989847c54d1989fa64cbe7fe8f0ce3f1b425bb8ef0ac1970914d72fc-light.svg) ![Data Firehose · Billed ingestion: monthly service charges by Billed ingestion. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/46d1f917a8dc6481afeec90459bc7b51bc54fbd117c246923e07aa363dbade20-dark.svg) 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. | Billed ingestion (GiB/month) | Kinesis Data Firehose | Target scenario | OCI Streaming | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | OCI Streaming (one staging copy) | 118.18 | 118.18 | | 0 | 0.00 | OCI Streaming (two staging copies) | 236.36 | 236.36 | | 1 | 0.03 | OCI Streaming (one staging copy) | 118.19 | 118.16 | | 1 | 0.03 | OCI Streaming (two staging copies) | 236.37 | 236.34 | | 10 | 0.29 | OCI Streaming (one staging copy) | 118.33 | 118.04 | | 10 | 0.29 | OCI Streaming (two staging copies) | 236.50 | 236.21 | | 100 | 2.90 | OCI Streaming (one staging copy) | 119.65 | 116.75 | | 100 | 2.90 | OCI Streaming (two staging copies) | 237.83 | 234.93 | | 1,000 | 29.00 | OCI Streaming (one staging copy) | 132.92 | 103.92 | | 1,000 | 29.00 | OCI Streaming (two staging copies) | 251.10 | 222.10 | | 10,000 | 290.00 | OCI Streaming (one staging copy) | 366.78 | 76.78 | | 10,000 | 290.00 | OCI Streaming (two staging copies) | 586.14 | 296.14 | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 GiB/month to 4 vCPU, 16 GiB memory and 100 GiB SSD at 10,000 GiB/month. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | OCI Streaming (one staging copy) | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | OCI Streaming (one staging copy) | Representative record size | 1,024 | bytes | | OCI Streaming (one staging copy) | Output bytes / input bytes | 1 | fraction | | OCI Streaming (one staging copy) | Buffer residence | 60 | seconds | | OCI Streaming (one staging copy) | Staging metadata per record | 256 | bytes | | OCI Streaming (one staging copy) | Object sink retention | 30 | days | | OCI Streaming (one staging copy) | Output object size | 5 | MiB | | OCI Streaming (one staging copy) | Delivery worker CPU per record | 0.1 | vCPU-ms | | OCI Streaming (one staging copy) | Target price guess · read | 0 | USD/read | | OCI Streaming (one staging copy) | Target price guess · write | 0 | USD/write | | OCI Streaming (one staging copy) | Target price guess · provider operation | 0 | USD/provider operation | | OCI Streaming (one staging copy) | Target list price · GiB-month | 0.146 | USD/GiB-month | | OCI Streaming (one staging copy) | Target list price · published GiB | 0.025 | USD/published GiB | | OCI Streaming (one staging copy) | Target list price · delivered GiB | 0.025 | USD/delivered GiB | | OCI Streaming (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB | | OCI Streaming (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | OCI Streaming (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | OCI Streaming (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | OCI Streaming (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | OCI Streaming (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month | | OCI Streaming (one staging copy) | Target price guess · input token | 0 | USD/input token | | OCI Streaming (one staging copy) | Target price guess · output token | 0 | USD/output token | | OCI Streaming (one staging copy) | Target monthly base charge | 0 | USD/month | | OCI Streaming (one staging copy) | Approximate target service minimum | 0 | USD/month | | OCI Streaming (one staging copy) | Minimum primary CPU | 2 | vCPU | | OCI Streaming (one staging copy) | Minimum primary RAM | 8 | GiB | | OCI Streaming (one staging copy) | Minimum primary disk | 100 | GiB | | OCI Streaming (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 | | OCI Streaming (one staging copy) | Allocated share of provisioned cost | 1 | fraction | | OCI Streaming (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | OCI Streaming (one staging copy) | Planning peak / mean work | 2 | multiplier | | OCI Streaming (one staging copy) | Planning primary CPU utilization | 0.7 | fraction | | OCI Streaming (one staging copy) | Resident state reserved in RAM | 0.1 | fraction | | OCI Streaming (one staging copy) | Planning disk utilization | 0.8 | fraction | | OCI Streaming (one staging copy) | Maintenance and log disk reserve | 20 | GiB | | OCI Streaming (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | OCI Streaming (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | OCI Streaming (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | OCI Streaming (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | OCI Streaming (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write | | OCI Streaming (two staging copies) | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | OCI Streaming (two staging copies) | Representative record size | 1,024 | bytes | | OCI Streaming (two staging copies) | Output bytes / input bytes | 1 | fraction | | OCI Streaming (two staging copies) | Buffer residence | 60 | seconds | | OCI Streaming (two staging copies) | Staging metadata per record | 256 | bytes | | OCI Streaming (two staging copies) | Object sink retention | 30 | days | | OCI Streaming (two staging copies) | Output object size | 5 | MiB | | OCI Streaming (two staging copies) | Delivery worker CPU per record | 0.1 | vCPU-ms | | OCI Streaming (two staging copies) | Target price guess · read | 0 | USD/read | | OCI Streaming (two staging copies) | Target price guess · write | 0 | USD/write | | OCI Streaming (two staging copies) | Target price guess · provider operation | 0 | USD/provider operation | | OCI Streaming (two staging copies) | Target list price · GiB-month | 0.146 | USD/GiB-month | | OCI Streaming (two staging copies) | Target list price · published GiB | 0.025 | USD/published GiB | | OCI Streaming (two staging copies) | Target list price · delivered GiB | 0.025 | USD/delivered GiB | | OCI Streaming (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB | | OCI Streaming (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | OCI Streaming (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | OCI Streaming (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | OCI Streaming (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | OCI Streaming (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month | | OCI Streaming (two staging copies) | Target price guess · input token | 0 | USD/input token | | OCI Streaming (two staging copies) | Target price guess · output token | 0 | USD/output token | | OCI Streaming (two staging copies) | Target monthly base charge | 0 | USD/month | | OCI Streaming (two staging copies) | Approximate target service minimum | 0 | USD/month | | OCI Streaming (two staging copies) | Minimum primary CPU | 2 | vCPU | | OCI Streaming (two staging copies) | Minimum primary RAM | 8 | GiB | | OCI Streaming (two staging copies) | Minimum primary disk | 100 | GiB | | OCI Streaming (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 | | OCI Streaming (two staging copies) | Allocated share of provisioned cost | 1 | fraction | | OCI Streaming (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | OCI Streaming (two staging copies) | Planning peak / mean work | 2 | multiplier | | OCI Streaming (two staging copies) | Planning primary CPU utilization | 0.7 | fraction | | OCI Streaming (two staging copies) | Resident state reserved in RAM | 0.1 | fraction | | OCI Streaming (two staging copies) | Planning disk utilization | 0.8 | fraction | | OCI Streaming (two staging copies) | Maintenance and log disk reserve | 20 | GiB | | OCI Streaming (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | OCI Streaming (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | OCI Streaming (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | OCI Streaming (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | OCI Streaming (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Billed GiB includes per-record rounding; physical bytes can be much lower for small records. 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. * The landing buffer, durable staging, delivery workers and object sink are separate allocations. Primary stored GiB is retained landing payload; staging adds delivery metadata. * Object sink retention and PUTs are priced separately from the landing backend. Even an object-store landing target needs the explicitly modeled temporary buffer allocation. * These retention and sink-write assumptions are provisional; a broker-only subtotal does not price the complete pipeline. * 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. * 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](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](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](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. * The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonKinesisFirehose offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json) * OCI price list API: [https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/](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. * Dynamic partitioning, format conversion, VPC delivery and origin sink charges; transformation-specific compute. * 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-58fa05b1b7165c11f9ab9ab5b17c9cfc69e313e3` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonKinesisFirehose offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json), [OCI price list API](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/). **Data Firehose → 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. | Monthly component | USD | | - | -: | | Origin: Billed ingestion | 0.00 | | Target: Target retained physical data | 0.00 | | Target: Additional broker replica storage | 0.00 | | Target: Target ingress events | 0.00 | | Target: Published bytes | 0.00 | | Target: Delivered bytes | 0.00 | | Target: Target native provider operations | 0.00 | | Target: Execution or worker CPU | 0.00 | | Target: Execution or worker RAM | 0.00 | | Target: Selected billable network | 0.00 | | Target: Independent native resources | 0.00 | | Target: Independent native resources | 0.00 | | Target: Durable staging CPU | 60.30 | | Target: Durable staging RAM | 40.88 | | Target: Durable staging disk | 17.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **118.18** | 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. * Dynamic partitioning, format conversion, VPC delivery and origin sink charges; transformation-specific compute. * 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** | Input | Value | Unit | | - | -: | - | | Origin list price · Billed ingestion | 0.029 | USD/GiB after5-KiB record rounding | | Representative record size | 1,024 | bytes | | Output bytes / input bytes | 1 | fraction | | Buffer residence | 60 | seconds | | Staging metadata per record | 256 | bytes | | Object sink retention | 30 | days | | Output object size | 5 | MiB | | Delivery worker CPU per record | 0.1 | vCPU-ms | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.146 | USD/GiB-month | | Target list price · published GiB | 0.025 | USD/published GiB | | Target list price · delivered GiB | 0.025 | USD/delivered GiB | | Target price guess · network GiB | 0 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target price guess · vCPU-hour | 0 | USD/vCPU-hour | | Target price guess · GiB-hour | 0 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Approximate target service minimum | 0 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Billed ingestion | 0 | GiB after5-KiB record rounding | * 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. * Explicit durable staging footprint: 0 GiB-month. * 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. * The landing buffer, durable staging, delivery workers and object sink are separate allocations. Primary stored GiB is retained landing payload; staging adds delivery metadata. * Object sink retention and PUTs are priced separately from the landing backend. Even an object-store landing target needs the explicitly modeled temporary buffer allocation. * These retention and sink-write assumptions are provisional; a broker-only subtotal does not price the complete pipeline. * 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. * 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](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](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](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. * The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. List prices read: 2026-10-22. Model: `plan-58fa05b1b7165c11f9ab9ab5b17c9cfc69e313e3` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonKinesisFirehose offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesisFirehose/current/us-east-1/index.json), [OCI price list API](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/). ## 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](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method, what the estimates include and how to read their qualifications. | Backend | Sampled workload | Price basis | Origin USD/month | Backend USD/month | Difference | Mapping | | - | - | - | -: | -: | -: | - | | Azure Event Hubs | Billed ingestion: 100 GiB/month; one staging copy | Cited list prices, 2026-10-22 | 2.90 | 141.14 | +138.24 | Service adapter | | DigitalOcean Managed Kafka | Billed ingestion: 100 GiB/month; one copy | Cited list prices, 2026-10-22 | 2.90 | 198.87 | +195.97 | Service adapter | | OCI Streaming | Billed ingestion: 100 GiB/month; one staging copy | Cited list prices, 2026-10-22 | 2.90 | 119.65 | +116.75 | Service adapter | | Pub/Sub | Billed ingestion: 100 GiB/month; one staging copy | Cited list prices, 2026-10-22 | 2.90 | 120.21 | +117.31 | Service adapter | | Strimzi Kafka | Billed ingestion: 100 GiB/month; one copy | Cited list prices, 2026-10-22 | 2.90 | 81.37 | +78.47 | Service adapter | 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](https://docs.tensor9.com/cloud-adapter-early-access/costs/kinesis.md). ## Service level agreements > [!WARNING] > > These tables show Tensor9's standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment. 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](https://docs.tensor9.com/cloud-adapter-early-access/support/service-adapter-slas.md), [measurement rules](https://docs.tensor9.com/cloud-adapter-early-access/support/service-levels.md), and [scaling conditions](https://docs.tensor9.com/cloud-adapter-early-access/support/scaling-and-limits.md). ### Kinesis Data Firehose to Azure Event Hubs | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Small delivery-record acceptance adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::firehose`: `PutRecord` | One record at most 4 KiB before base64 encoding, stream configuration at most 32 KiB. Measures ingest acceptance, not waiting for a delivery buffer to fill or for the sink to receive it. | | Bounded delivery-record batch acceptance adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::firehose`: `PutRecordBatch` | At most 100 records and 400 KiB aggregate decoded data. Each record's result is preserved. Destination transformation and scheduled flush completion are separate. | | Delivery-stream configuration responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::firehose`: `CreateDeliveryStream`, `DeleteDeliveryStream` | One delivery stream, at most 32 KiB configuration and one configured destination. Measures validation and request acceptance, not the time to provision native resources or drain retained data. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::firehose`: `PutRecord`, `PutRecordBatch`, `CreateDeliveryStream`, `DeleteDeliveryStream` | A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **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`, Event Hubs accepts the buffered records; partition capacity and producer quotas limit native ingestion. The adapter's ingest response and the delivery agent's sink write are distinct. Buffer size and interval control when accepted records are flushed. A Lambda transform or format conversion adds a later processing stage; the PutRecord target must not be read as a deadline for completing that pipeline. #### How the latency targets were chosen **Small delivery-record acceptance: +3 ms monthly p99 (adapter-added).** `PutRecord`. JSON/base64 decoding, stream selection, bounded record construction and response encoding. Adapter-owned configuration and acceptance bookkeeping remain included. **Bounded delivery-record batch acceptance: +10 ms monthly p99 (adapter-added).** `PutRecordBatch`. Decode each record, construct bounded native batch requests and assemble partial results. The bound covers records as well as bytes. **Delivery-stream configuration responses: +20 ms monthly p99 (adapter-added).** `CreateDeliveryStream`, `DeleteDeliveryStream`. Persist stream identity and delivery settings before acknowledging the configuration request; adapter catalog and coordination storage waits count. 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 record ingestion separately from buffering and destination delivery. Track records and bytes per second, active streams, buffer occupancy and oldest undelivered record, plus target partition capacity and consumer lag. A small ingest response does not prove that delivery keeps up. The agreement bounds batch size, active streams, transformation work and burst accumulation. Tensor9 scales adapter workers within that envelope; the customer supplies sufficient native landing-store and sink capacity. 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 A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. #### Example and diagnosis For delivery stream `application-audit`, submit 80 records of 2 KiB each. This fits the batch-acceptance row. If the configured delivery interval is 60 seconds, a record waiting inside that intended buffer has not breached the 10 ms ingest target. A growing backlog after successive flushes requires inspecting delivery workers, transformation errors and target sink capacity; request translation timing alone does not explain it. 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 Firehose to DigitalOcean Managed Kafka | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Small delivery-record acceptance adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::firehose`: `PutRecord` | One record at most 4 KiB before base64 encoding, stream configuration at most 32 KiB. Measures ingest acceptance, not waiting for a delivery buffer to fill or for the sink to receive it. | | Bounded delivery-record batch acceptance adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::firehose`: `PutRecordBatch` | At most 100 records and 400 KiB aggregate decoded data. Each record's result is preserved. Destination transformation and scheduled flush completion are separate. | | Delivery-stream configuration responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::firehose`: `CreateDeliveryStream`, `DeleteDeliveryStream` | One delivery stream, at most 32 KiB configuration and one configured destination. Measures validation and request acceptance, not the time to provision native resources or drain retained data. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::firehose`: `PutRecord`, `PutRecordBatch`, `CreateDeliveryStream`, `DeleteDeliveryStream` | A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **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 `digitalocean::1.0.0::database::kafka`, DigitalOcean's managed Kafka stores buffered records; broker partitions, producer limits and consumer lag are separate from adapter request handling. The adapter's ingest response and the delivery agent's sink write are distinct. Buffer size and interval control when accepted records are flushed. A Lambda transform or format conversion adds a later processing stage; the PutRecord target must not be read as a deadline for completing that pipeline. #### How the latency targets were chosen **Small delivery-record acceptance: +3 ms monthly p99 (adapter-added).** `PutRecord`. JSON/base64 decoding, stream selection, bounded record construction and response encoding. Adapter-owned configuration and acceptance bookkeeping remain included. **Bounded delivery-record batch acceptance: +10 ms monthly p99 (adapter-added).** `PutRecordBatch`. Decode each record, construct bounded native batch requests and assemble partial results. The bound covers records as well as bytes. **Delivery-stream configuration responses: +20 ms monthly p99 (adapter-added).** `CreateDeliveryStream`, `DeleteDeliveryStream`. Persist stream identity and delivery settings before acknowledging the configuration request; adapter catalog and coordination storage waits count. 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 record ingestion separately from buffering and destination delivery. Track records and bytes per second, active streams, buffer occupancy and oldest undelivered record, plus target partition capacity and consumer lag. A small ingest response does not prove that delivery keeps up. The agreement bounds batch size, active streams, transformation work and burst accumulation. Tensor9 scales adapter workers within that envelope; the customer supplies sufficient native landing-store and sink capacity. 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 A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. #### Example and diagnosis For delivery stream `application-audit`, submit 80 records of 2 KiB each. This fits the batch-acceptance row. If the configured delivery interval is 60 seconds, a record waiting inside that intended buffer has not breached the 10 ms ingest target. A growing backlog after successive flushes requires inspecting delivery workers, transformation errors and target sink capacity; request translation timing alone does not explain it. 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 Firehose to Pub/Sub | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Small delivery-record acceptance adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::firehose`: `PutRecord` | One record at most 4 KiB before base64 encoding, stream configuration at most 32 KiB. Measures ingest acceptance, not waiting for a delivery buffer to fill or for the sink to receive it. | | Bounded delivery-record batch acceptance adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::firehose`: `PutRecordBatch` | At most 100 records and 400 KiB aggregate decoded data. Each record's result is preserved. Destination transformation and scheduled flush completion are separate. | | Delivery-stream configuration responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::firehose`: `CreateDeliveryStream`, `DeleteDeliveryStream` | One delivery stream, at most 32 KiB configuration and one configured destination. Measures validation and request acceptance, not the time to provision native resources or drain retained data. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::firehose`: `PutRecord`, `PutRecordBatch`, `CreateDeliveryStream`, `DeleteDeliveryStream` | A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **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`, Pub/Sub accepts buffered records; publication, subscription backlog and acknowledgement are separate stages. The adapter's ingest response and the delivery agent's sink write are distinct. Buffer size and interval control when accepted records are flushed. A Lambda transform or format conversion adds a later processing stage; the PutRecord target must not be read as a deadline for completing that pipeline. #### How the latency targets were chosen **Small delivery-record acceptance: +3 ms monthly p99 (adapter-added).** `PutRecord`. JSON/base64 decoding, stream selection, bounded record construction and response encoding. Adapter-owned configuration and acceptance bookkeeping remain included. **Bounded delivery-record batch acceptance: +10 ms monthly p99 (adapter-added).** `PutRecordBatch`. Decode each record, construct bounded native batch requests and assemble partial results. The bound covers records as well as bytes. **Delivery-stream configuration responses: +20 ms monthly p99 (adapter-added).** `CreateDeliveryStream`, `DeleteDeliveryStream`. Persist stream identity and delivery settings before acknowledging the configuration request; adapter catalog and coordination storage waits count. 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 record ingestion separately from buffering and destination delivery. Track records and bytes per second, active streams, buffer occupancy and oldest undelivered record, plus target partition capacity and consumer lag. A small ingest response does not prove that delivery keeps up. The agreement bounds batch size, active streams, transformation work and burst accumulation. Tensor9 scales adapter workers within that envelope; the customer supplies sufficient native landing-store and sink capacity. 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 A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. #### Example and diagnosis For delivery stream `application-audit`, submit 80 records of 2 KiB each. This fits the batch-acceptance row. If the configured delivery interval is 60 seconds, a record waiting inside that intended buffer has not breached the 10 ms ingest target. A growing backlog after successive flushes requires inspecting delivery workers, transformation errors and target sink capacity; request translation timing alone does not explain it. 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 Firehose to OCI Streaming | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Small delivery-record acceptance adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::firehose`: `PutRecord` | One record at most 4 KiB before base64 encoding, stream configuration at most 32 KiB. Measures ingest acceptance, not waiting for a delivery buffer to fill or for the sink to receive it. | | Bounded delivery-record batch acceptance adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::firehose`: `PutRecordBatch` | At most 100 records and 400 KiB aggregate decoded data. Each record's result is preserved. Destination transformation and scheduled flush completion are separate. | | Delivery-stream configuration responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::firehose`: `CreateDeliveryStream`, `DeleteDeliveryStream` | One delivery stream, at most 32 KiB configuration and one configured destination. Measures validation and request acceptance, not the time to provision native resources or drain retained data. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::firehose`: `PutRecord`, `PutRecordBatch`, `CreateDeliveryStream`, `DeleteDeliveryStream` | A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **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`, OCI Streaming accepts the buffered records; partition limits and retained positions constrain ingestion and replay. The adapter's ingest response and the delivery agent's sink write are distinct. Buffer size and interval control when accepted records are flushed. A Lambda transform or format conversion adds a later processing stage; the PutRecord target must not be read as a deadline for completing that pipeline. #### How the latency targets were chosen **Small delivery-record acceptance: +3 ms monthly p99 (adapter-added).** `PutRecord`. JSON/base64 decoding, stream selection, bounded record construction and response encoding. Adapter-owned configuration and acceptance bookkeeping remain included. **Bounded delivery-record batch acceptance: +10 ms monthly p99 (adapter-added).** `PutRecordBatch`. Decode each record, construct bounded native batch requests and assemble partial results. The bound covers records as well as bytes. **Delivery-stream configuration responses: +20 ms monthly p99 (adapter-added).** `CreateDeliveryStream`, `DeleteDeliveryStream`. Persist stream identity and delivery settings before acknowledging the configuration request; adapter catalog and coordination storage waits count. 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 record ingestion separately from buffering and destination delivery. Track records and bytes per second, active streams, buffer occupancy and oldest undelivered record, plus target partition capacity and consumer lag. A small ingest response does not prove that delivery keeps up. The agreement bounds batch size, active streams, transformation work and burst accumulation. Tensor9 scales adapter workers within that envelope; the customer supplies sufficient native landing-store and sink capacity. 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 A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. #### Example and diagnosis For delivery stream `application-audit`, submit 80 records of 2 KiB each. This fits the batch-acceptance row. If the configured delivery interval is 60 seconds, a record waiting inside that intended buffer has not breached the 10 ms ingest target. A growing backlog after successive flushes requires inspecting delivery workers, transformation errors and target sink capacity; request translation timing alone does not explain it. 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 Firehose to Strimzi Kafka | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Small delivery-record acceptance adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::firehose`: `PutRecord` | One record at most 4 KiB before base64 encoding, stream configuration at most 32 KiB. Measures ingest acceptance, not waiting for a delivery buffer to fill or for the sink to receive it. | | Bounded delivery-record batch acceptance adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::firehose`: `PutRecordBatch` | At most 100 records and 400 KiB aggregate decoded data. Each record's result is preserved. Destination transformation and scheduled flush completion are separate. | | Delivery-stream configuration responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::firehose`: `CreateDeliveryStream`, `DeleteDeliveryStream` | One delivery stream, at most 32 KiB configuration and one configured destination. Measures validation and request acceptance, not the time to provision native resources or drain retained data. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::firehose`: `PutRecord`, `PutRecordBatch`, `CreateDeliveryStream`, `DeleteDeliveryStream` | A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **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`, Kafka stores buffered records; topic partitions, producer acknowledgements and delivery-worker consumer positions determine the landing-store behavior. The adapter's ingest response and the delivery agent's sink write are distinct. Buffer size and interval control when accepted records are flushed. A Lambda transform or format conversion adds a later processing stage; the PutRecord target must not be read as a deadline for completing that pipeline. #### How the latency targets were chosen **Small delivery-record acceptance: +3 ms monthly p99 (adapter-added).** `PutRecord`. JSON/base64 decoding, stream selection, bounded record construction and response encoding. Adapter-owned configuration and acceptance bookkeeping remain included. **Bounded delivery-record batch acceptance: +10 ms monthly p99 (adapter-added).** `PutRecordBatch`. Decode each record, construct bounded native batch requests and assemble partial results. The bound covers records as well as bytes. **Delivery-stream configuration responses: +20 ms monthly p99 (adapter-added).** `CreateDeliveryStream`, `DeleteDeliveryStream`. Persist stream identity and delivery settings before acknowledging the configuration request; adapter catalog and coordination storage waits count. 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 record ingestion separately from buffering and destination delivery. Track records and bytes per second, active streams, buffer occupancy and oldest undelivered record, plus target partition capacity and consumer lag. A small ingest response does not prove that delivery keeps up. The agreement bounds batch size, active streams, transformation work and burst accumulation. Tensor9 scales adapter workers within that envelope; the customer supplies sufficient native landing-store and sink capacity. 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 A successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag. #### Example and diagnosis For delivery stream `application-audit`, submit 80 records of 2 KiB each. This fits the batch-acceptance row. If the configured delivery interval is 60 seconds, a record waiting inside that intended buffer has not breached the 10 ms ingest target. A growing backlog after successive flushes requires inspecting delivery workers, transformation errors and target sink capacity; request translation timing alone does not explain it. 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. ## Install and run The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. Set `T9_API_KEY` as described in [Install and Authenticate](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/install-and-authenticate.md), then list the adapters your account may use with this origin: ```sh theme={null} tensor9 adapt svc list \ -origin aws::1.0.0::kinesis::firehose ``` The result is limited to directed mappings for this origin that your account is entitled to use. Use a returned backend identifier when configuring the adapter or investigating a request. Request binary access from [hello@tensor9.com](mailto:hello@tensor9.com) if your account does not yet include this direction. ## Existing data and credentials Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target. ## Configure, tune and debug Start with [setup](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/overview.md) and [configuration](https://docs.tensor9.com/cloud-adapter-early-access/configuration/overview.md). Use [tuning](https://docs.tensor9.com/cloud-adapter-early-access/tuning/overview.md) to understand supported request tags, [debugging](https://docs.tensor9.com/cloud-adapter-early-access/debugging/overview.md) to investigate a request, and [High Fidelity Cloud Emulators](https://docs.tensor9.com/cloud-adapter-early-access/local-testing/overview.md) to validate a bounded reproduction. For requests that go through an entitled service adapter, use [tensor9 explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/explain.md) and [x-t9-explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/response-headers.md) to inspect the selected mapping. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.