Skip to main content
On this page

​
Coverage by target cloud

​
How the targets compare

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

​
Max adaptation

​
On Google Cloud

​
Via Pub/Sub

​
Acceptance, buffering and delivery

The application sends Firehose PutRecord or PutRecordBatch requests to the Tensor9 adapter. The target design buffers accepted records on Google Cloud Pub/Sub, then a delivery worker sends batches to the configured destination. The object-storage destination for this mapping is Google Cloud Storage. Success from the ingest API means acceptance into the buffer, not confirmation from the final destination. Inspect individual results when a batch has both successful and failed records. Size and interval settings control when a batch is ready for delivery. A low-volume stream may wait for the interval; a busy stream may reach the size threshold first. Worker scheduling, optional transformation and destination response time also affect delivery latency, so the buffering interval is not an end-to-end latency guarantee.

​
Transformation and destination setup

The intended delivery path can run a batch through the selected Lambda adapter before writing its output. JSON-to-Parquet conversion uses a default or inferred schema; it does not import the declared Glue table schema. Validate field types and the resulting files with their readers. HTTP, search and SaaS destinations require their own credentials, reachable endpoints and delivery formats. A warehouse loader delivers records to the selected warehouse. Configure its destination tables and load format separately; this mapping does not migrate a Redshift database, schema, SQL queries or warehouse workload.

​
Failure recovery and migration

Delivery must tolerate a destination accepting a batch before the worker records success. A retry can therefore repeat records or create a duplicate object. Downstream processing should identify duplicates. Monitor pending work, retry failures and destination delivery, rather than using successful PutRecord calls as a delivery-health signal. Provision destination storage, credentials and transformation dependencies before switching producers. Allow the old AWS stream to finish delivering its buffered records; those pending records are not copied into the new buffer. Test the selected destination with representative batches, including destination failures and retries. Measure delivery delay and sustained throughput with the actual transform, batch settings and destination.

​
On Google Cloud and Private Kubernetes

​
Via Strimzi Kafka

​
Acceptance, buffering and delivery

The application sends Firehose PutRecord or PutRecordBatch requests to the Tensor9 adapter. The target design buffers accepted records on Apache Kafka (Strimzi) on the target cluster, then a delivery worker sends batches to the configured destination. The object-storage destination for this mapping is the appliance object store (MinIO). Success from the ingest API means acceptance into the buffer, not confirmation from the final destination. Inspect individual results when a batch has both successful and failed records. Size and interval settings control when a batch is ready for delivery. A low-volume stream may wait for the interval; a busy stream may reach the size threshold first. Worker scheduling, optional transformation and destination response time also affect delivery latency, so the buffering interval is not an end-to-end latency guarantee.

​
Transformation and destination setup

The intended delivery path can run a batch through the selected Lambda adapter before writing its output. JSON-to-Parquet conversion uses a default or inferred schema; it does not import the declared Glue table schema. Validate field types and the resulting files with their readers. HTTP, search and SaaS destinations require their own credentials, reachable endpoints and delivery formats. A warehouse loader delivers records to the selected warehouse. Configure its destination tables and load format separately; this mapping does not migrate a Redshift database, schema, SQL queries or warehouse workload.

​
Failure recovery and migration

Delivery must tolerate a destination accepting a batch before the worker records success. A retry can therefore repeat records or create a duplicate object. Downstream processing should identify duplicates. Monitor pending work, retry failures and destination delivery, rather than using successful PutRecord calls as a delivery-health signal. Provision destination storage, credentials and transformation dependencies before switching producers. Allow the old AWS stream to finish delivering its buffered records; those pending records are not copied into the new buffer. Test the selected destination with representative batches, including destination failures and retries. Measure delivery delay and sustained throughput with the actual transform, batch settings and destination.

​
On Azure

​
Acceptance, buffering and delivery

The application sends Firehose PutRecord or PutRecordBatch requests to the Tensor9 adapter. The target design buffers accepted records on Azure Event Hubs, then a delivery worker sends batches to the configured destination. The object-storage destination for this mapping is Azure Blob Storage. Success from the ingest API means acceptance into the buffer, not confirmation from the final destination. Inspect individual results when a batch has both successful and failed records. Size and interval settings control when a batch is ready for delivery. A low-volume stream may wait for the interval; a busy stream may reach the size threshold first. Worker scheduling, optional transformation and destination response time also affect delivery latency, so the buffering interval is not an end-to-end latency guarantee.

​
Transformation and destination setup

The intended delivery path can run a batch through the selected Lambda adapter before writing its output. JSON-to-Parquet conversion uses a default or inferred schema; it does not import the declared Glue table schema. Validate field types and the resulting files with their readers. HTTP, search and SaaS destinations require their own credentials, reachable endpoints and delivery formats. A warehouse loader delivers records to the selected warehouse. Configure its destination tables and load format separately; this mapping does not migrate a Redshift database, schema, SQL queries or warehouse workload.

​
Failure recovery and migration

Delivery must tolerate a destination accepting a batch before the worker records success. A retry can therefore repeat records or create a duplicate object. Downstream processing should identify duplicates. Monitor pending work, retry failures and destination delivery, rather than using successful PutRecord calls as a delivery-health signal. Provision destination storage, credentials and transformation dependencies before switching producers. Allow the old AWS stream to finish delivering its buffered records; those pending records are not copied into the new buffer. Test the selected destination with representative batches, including destination failures and retries. Measure delivery delay and sustained throughput with the actual transform, batch settings and destination.

​
On OCI

​
Acceptance, buffering and delivery

The application sends Firehose PutRecord or PutRecordBatch requests to the Tensor9 adapter. The target design buffers accepted records on OCI Streaming, then a delivery worker sends batches to the configured destination. The object-storage destination for this mapping is OCI Object Storage. Success from the ingest API means acceptance into the buffer, not confirmation from the final destination. Inspect individual results when a batch has both successful and failed records. Size and interval settings control when a batch is ready for delivery. A low-volume stream may wait for the interval; a busy stream may reach the size threshold first. Worker scheduling, optional transformation and destination response time also affect delivery latency, so the buffering interval is not an end-to-end latency guarantee.

​
Transformation and destination setup

The intended delivery path can run a batch through the selected Lambda adapter before writing its output. JSON-to-Parquet conversion uses a default or inferred schema; it does not import the declared Glue table schema. Validate field types and the resulting files with their readers. HTTP, search and SaaS destinations require their own credentials, reachable endpoints and delivery formats. A warehouse loader delivers records to the selected warehouse. Configure its destination tables and load format separately; this mapping does not migrate a Redshift database, schema, SQL queries or warehouse workload.

​
Failure recovery and migration

Delivery must tolerate a destination accepting a batch before the worker records success. A retry can therefore repeat records or create a duplicate object. Downstream processing should identify duplicates. Monitor pending work, retry failures and destination delivery, rather than using successful PutRecord calls as a delivery-health signal. Provision destination storage, credentials and transformation dependencies before switching producers. Allow the old AWS stream to finish delivering its buffered records; those pending records are not copied into the new buffer. Test the selected destination with representative batches, including destination failures and retries. Measure delivery delay and sustained throughput with the actual transform, batch settings and destination. Service Catalog.