Supported environments
- Akamai
- Azure
- DigitalOcean
- Google Cloud
- OCI
- Private Kubernetes
- Scaleway
How the targets compare
Each row compares a capability of SNS with its adaptation on each target. A dash means this profile does not state the capability for that target.Cloud Adapter
On Akamai, Azure, DigitalOcean, OCI, Private Kubernetes, and Scaleway
PostgreSQL
How it works
The application keeps its SNS client and uses a service adapter in the target cluster. PostgreSQL retains notification bytes; a separate durable SNS store records topic and subscription lifetimes, filters, receiver permissions and delivery results. Publish holds the bytes without sending them, then commits the publication and selected deliveries. Only after both writes succeed does it return aMessageId. A process failure between writes leaves unreferenced bytes, not permission to contact a recipient. Committed work remains discoverable after workers restart.
Message storage and delivery admission are separate durable writes.
Delivery and ownership
The publication’s captured subscription and filter revisions determine selection. Current receiver permission is checked before sending. A retired subscription cannot authorize another attempt, and a replacement subscription does not inherit its backlog. Each recipient has an independent outcome. Once SQS durably enqueues a message, it owns that message; after Lambda durably accepts an asynchronous event, it owns function execution and retries. SNS continues to own HTTP and HTTPS delivery attempts. An uncertain acceptance can result in a repeated notification with the sameMessageId, so recipient side effects must tolerate duplicates.
Limitations
- Standard topics. FIFO ordering, deduplication and MessageGroupId are refused.
- Four subscriber protocols. SQS, HTTP, HTTPS and Lambda are supported; email, SMS, Firehose and mobile push are refused.
- Filter and raw-delivery scope. Attribute and JSON-body filters use a restricted grammar. Raw delivery applies only to SQS; HTTP and HTTPS receive notification envelopes.
- Receiver configuration. Queues must permit the topic. HTTP and HTTPS require confirmation and tenant signing-key trust; AWS SigningCertURL-only verification is incompatible.
- Policies and redrive. AWS topic resource policies are not translated, and subscription RedrivePolicy is refused.
Other considerations
The deployment operator runs PostgreSQL storage, replication, backups and recovery on the target cluster. Size the database for retained notifications and connection demand, and preserve both payloads and the separate SNS records during backup and restore. Validate destination permissions and restart recovery before redirecting publishers. Existing AWS delivery work is not copied into PostgreSQL; drain or expire it on AWS as part of the cutover.On Azure
Azure Service Bus Premium
How it works
Each SNS topic maps to a Service Bus Premium topic with a durable broker subscription for each SNS subscription. The application keeps its SNS ARNs. Subscription lifetimes, filter revisions and receiver consent remain in separate SNS records; the broker owns retained message copies. A worker receives a copy under PeekLock, matches it to the captured SNS routing revision and checks current receiver permission before sending. Results are independent across subscriptions. A successful Publish confirms acceptance into the delivery system, not receipt by every destination.
A Service Bus lock coordinates a receive; it does not authorize the destination.
Restart and delivery outcomes
Workers recover SNS subscription records, create or verify the corresponding Service Bus entities and read their settings before receiving. A new subscription lifetime uses a new binding; messages retained for a removed subscription cannot become work for its replacement. Broker completion follows a recorded delivery result. A temporary failure leaves the copy for redelivery. If the destination accepts a notification before the worker loses its lock or acknowledgement, a later attempt may deliver it again. Recipients must make repeated effects safe. SQS takes ownership after durable enqueue. Lambda takes ownership of execution and execution retries after durable asynchronous acceptance; SNS does not wait for the handler to finish or retry its execution. HTTP and HTTPS responses determine whether SNS completes, retries or stops that delivery.Limitations
- Standard SNS topics. Service Bus sessions are not presented as SNS FIFO ordering or deduplication.
- SNS filter subset. Captured SNS policies are evaluated by the adapter; unsupported operators are refused.
- Four subscriber protocols. SQS, HTTP, HTTPS and Lambda are supported; email, SMS, Firehose and mobile push are refused.
- HTTP receiver setup. Confirmation and tenant signing-key trust are required; an AWS SigningCertURL-only verifier is incompatible. Plaintext HTTP requires explicit private-network approval.
- Policies and redrive. AWS topic resource policies are not translated, and SNS RedrivePolicy is refused. Service Bus dead-letter state is a separate broker facility.
Other considerations
Microsoft operates Service Bus. Configure namespace capacity, workload-identity access and private connectivity for the target Azure environment. The selected Premium namespace uses a 4096-KiB message limit that is read back before readiness; this is transport capacity, not an increase in the SNS Publish limit. An encoded notification must also fit its destination’s limit. Monitor backlog, message age, lock loss and dead-letter state alongside destination outcomes. Retain SNS subscription records during recovery as well as the broker entities. Validate destination receipt before cutover; outstanding AWS notifications are not transferred into Service Bus.Azure Database for PostgreSQL Flexible Server
How it works
The application keeps its SNS client while notification bytes are stored in Azure Database for PostgreSQL Flexible Server. Microsoft Entra workload identity and TLS provide database access. Durable SNS records retain subscription lifetimes, captured filters and receiver permissions separately from the message database. Publish saves the bytes before recording the publication and its selected deliveries. Success requires both writes; there is no transaction spanning the two stores. A failure between them leaves bytes that cannot be delivered. After acceptance, workers discover pending work from durable records.
Flexible Server stores the payload; separate SNS records govern delivery.
Delivery and database operations
A publication selects subscriptions using its captured filter revision. Each selected destination is checked against current receiver permission before an attempt. Removing and recreating a subscription does not give the replacement permission to receive the old subscription’s backlog. SQS owns a durably enqueued message. Lambda owns function execution and its retries after accepting an asynchronous event. SNS records those acceptances independently; an HTTP failure does not require repeating a completed queue delivery. An acceptance whose acknowledgement is lost can still cause a duplicate, so recipients must tolerate repeatedMessageId values.
Microsoft operates Flexible Server. Availability and recovery depend on the selected database configuration, region and backup policy. Size storage and connections for retained messages as well as normal traffic, and preserve SNS subscription and delivery records alongside the payload database.
Limitations
- Standard topics. FIFO ordering and deduplication are not provided.
- Filter subset. Message-attribute and JSON-body filters use a restricted grammar; unsupported operators are refused.
- Destination scope. SQS and unqualified Lambda destinations use their local service adapters in the same tenant and region. Email, SMS, Firehose and mobile push are refused.
- HTTP receiver changes. HTTP and HTTPS require recipient confirmation and tenant signing-key trust. An AWS SigningCertURL-only verifier is incompatible; plaintext HTTP also requires explicit private-network approval.
- Policies and redrive. AWS topic resource policies are not translated, and subscription RedrivePolicy is refused.
Other considerations
Verify Entra database access, TLS, queue consent and all destination paths before changing the publishing endpoint. Test restart and restore procedures using both durable stores. Database availability alone does not establish that a recipient can accept notifications. Cutover creates a separate delivery system. Drain or deliberately expire outstanding AWS notifications on AWS; they are not transferred into Flexible Server.On Google Cloud
Google Cloud Pub/Sub
How it works
The SNS service adapter maps topics to Google Cloud Pub/Sub and creates a durable pull subscription for each SNS subscription. The application continues to address SNS ARNs. Separate SNS records retain subscription lifetimes, filters and receiver consent; broker names and labels do not grant permission to send a notification. A publication records its captured routing revision. Workers match each broker copy to that revision, evaluate the selected SNS filter and check current receiver permission before delivery. Google operates broker storage and redelivery, while the adapter handles SNS recipient protocols.
Pub/Sub retains message copies; SNS records govern who may receive them.
Acknowledgement and recovery
Acknowledgement follows a recorded outcome: destination acceptance, a filter nonmatch, or a terminal refusal. Temporary failures leave work for broker redelivery. The acknowledgement deadline coordinates receipt of a broker copy; it does not replace the check of current subscription and destination permissions. After SQS enqueue, SQS owns the accepted message. Lambda owns execution retries after durable asynchronous acceptance. A lost acknowledgement can still repeat the handoff, so recipients must tolerate duplicates. On restart, workers recover subscription mappings from durable SNS records. A recreated subscription has a new lifetime and cannot receive a retired subscription’s retained work.Limitations
- SNS filter subset. Attribute and JSON-body filters are evaluated by the adapter rather than translated into Pub/Sub filters; unsupported operators are refused.
- Standard topics. Pub/Sub ordering keys are not exposed as SNS FIFO ordering or deduplication.
- Recipient scope. SQS, HTTP, HTTPS and Lambda are supported; email, SMS, Firehose and mobile push are refused.
- HTTP receiver setup. Confirmation and tenant signing-key trust are required. An AWS SigningCertURL-only verifier is incompatible. Plaintext HTTP requires explicit private-network approval.
- Policies and redrive. AWS topic resource policies are not translated, and subscription RedrivePolicy is refused.
Other considerations
Use workload identity for broker access and configure queue consent and endpoint reachability before publisher cutover. Retention and subscription backlog constrain how long a destination may remain unavailable. An empty broker subscription alone does not distinguish delivery from filtering or expiry. Outstanding AWS notifications remain on AWS. The June 2026 Publish benchmark measured a p50 of 57.12 ms through Pub/Sub and 9.27 ms on native SNS at 50 open-loop connections, with both paths sustaining about 100 operations per second. These figures cover Publish acceptance and exclude fan-out, filter evaluation and subscriber receipt.Google Cloud SQL for PostgreSQL
How it works
Applications use the SNS API and retain topic and subscription ARNs. Google Cloud SQL for PostgreSQL stores each notification’s bytes. A separate durable store holds SNS subscriptions, permissions and delivery records. The two stores have separate commits: the message is saved first, then the publication and its selected deliveries are recorded together. This order prevents an accepted delivery from referring to a message that was never saved. If the process stops between the writes, the stored bytes authorize no delivery. Once both writes succeed, workers can find pending work without relying on the publisher process’s memory.
Publish returns after the first two steps. Subscriber receipt happens later.
Delivery and retries
Subscription selection uses the filter revision captured for the publication. Before sending a selected notification, the worker checks that the subscription and receiver permission are still current. Unsubscribe prevents new delivery admissions; it cannot recall a message already accepted by a queue. Each subscription has its own result. SQS takes responsibility after durable enqueue, and Lambda takes responsibility for execution and execution retries after durable asynchronous acceptance. HTTP and HTTPS attempts remain with SNS until their responses are classified. If a destination accepts a notification but its acknowledgement or the delivery record is lost, another attempt can produce a duplicate with the sameMessageId. Recipients must make repeated effects safe.
Limitations
- Standard topics. FIFO topics, ordering and deduplication are outside this mapping.
- Filter subset. Message attributes and JSON bodies use a restricted filter grammar; unsupported operators are refused.
- Receiver setup. SQS queues must permit the topic. Lambda requires its local service adapter and an unqualified function destination. HTTP and HTTPS require confirmation and tenant signing-key trust; an AWS SigningCertURL-only verifier is incompatible.
- Protocol and redrive scope. SQS, HTTP, HTTPS and Lambda are supported. Email, SMS, mobile push, Firehose and subscription RedrivePolicy are refused.
- Topic access policies. AWS topic resource policies are not translated. Caller permissions and destination consent must be configured separately.
Other considerations
Google operates Cloud SQL maintenance and the database features selected for the deployment. Configure database capacity, private connectivity, TLS and backups for the expected workload. Recovery must preserve both the message database and the SNS subscription and delivery records; a backup of either one alone is insufficient. Before redirecting publishers, verify queue consent, destination receipt and recovery in the selected configuration. Existing AWS delivery backlog is not copied into Cloud SQL. Monitor database storage and connection pressure alongside pending deliveries and destination failures.Service level agreements
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.SNS (Simple Notification Service) to Azure Database for PostgreSQL Flexible Server
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
Forazure::1.0.0::postgresql::flexible, Publish persists accepted notifications and per-subscription delivery work in a PostgreSQL outbox. Workers deliver later and record their result. The latency row ends at API acceptance, not successful receipt by every subscriber.
How the latency targets were chosen
Bounded notification acceptance: 20 ms monthly p99.Publish. The PostgreSQL path persists per-subscriber delivery work; native brokers fan out differently. Adapter subscription/authorization/outbox work stays on the fabric clock.
Bounded notification batch acceptance: 50 ms monthly p99. PublishBatch. Batch decoding, target calls and delivery scheduling are bounded by both entries and fan-out.
Topic and subscription configuration: 20 ms monthly p99. ConfirmSubscription, CreateTopic, DeleteTopic, GetSubscriptionAttributes, GetTopicAttributes, ListTagsForResource, SetSubscriptionAttributes, SetTopicAttributes, Subscribe, TagResource, Unsubscribe, UntagResource. Configuration and authorization state must be persisted; waiting for a human or endpoint confirmation is not promised within this request-response budget.
Bounded topic and subscription pages: 20 ms monthly p99. ListSubscriptions, ListSubscriptionsByTopic, ListTopics. Persistent catalog reads and token/result generation are included.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Bound subscriptions per topic, filter complexity, payload bytes and queued deliveries as well as publish rate. A publish with 20 subscribers creates up to 20 units of delivery work. Scale request handlers and delivery workers independently, and watch outbox age or broker backlog. Subscriber timeouts and provider quotas can limit delivery even when the adapter accepts new work quickly; the agreement must state a separate delivery/backlog objective if one is required. 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 Publish must correspond to the documented durable acceptance point. Retries can duplicate downstream delivery, so consumers remain idempotent. Subscription activation must respect receiver consent and supported protocol rules. Filter policy, message attributes and FIFO behavior are limited by this target profile. Unsupported subscription or publish shapes are not implied by the numerical acceptance row.Example and diagnosis
For topicorder-created, publishing one 2 KiB event to ten subscriptions uses the single-publish row. The request can satisfy its SLA while an unreachable webhook accumulates retries; inspect delivery state separately. If adapter-owned outbox insertion is slow, that is fabric time rather than subscriber time and remains Tensor9’s responsibility.
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.
SNS (Simple Notification Service) to Azure Service Bus Premium
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
Forazure::1.0.0::servicebus, Publish maps to the native topic service, while adapter workers can pull broker subscriptions and forward notifications to the configured destination. Native topic acceptance and final HTTP/SQS/email delivery are different events; the request SLA covers the first adapter interaction.
How the latency targets were chosen
Bounded notification acceptance: 3 ms monthly p99.Publish. The PostgreSQL path persists per-subscriber delivery work; native brokers fan out differently. Adapter subscription/authorization/outbox work stays on the fabric clock.
Bounded notification batch acceptance: 10 ms monthly p99. PublishBatch. Batch decoding, target calls and delivery scheduling are bounded by both entries and fan-out.
Topic and subscription configuration: 20 ms monthly p99. ConfirmSubscription, CreateTopic, DeleteTopic, GetSubscriptionAttributes, GetTopicAttributes, ListTagsForResource, SetSubscriptionAttributes, SetTopicAttributes, Subscribe, TagResource, Unsubscribe, UntagResource. Configuration and authorization state must be persisted; waiting for a human or endpoint confirmation is not promised within this request-response budget.
Bounded topic and subscription pages: 20 ms monthly p99. ListSubscriptions, ListSubscriptionsByTopic, ListTopics. Persistent catalog reads and token/result generation are included.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Bound subscriptions per topic, filter complexity, payload bytes and queued deliveries as well as publish rate. A publish with 20 subscribers creates up to 20 units of delivery work. Scale request handlers and delivery workers independently, and watch outbox age or broker backlog. Subscriber timeouts and provider quotas can limit delivery even when the adapter accepts new work quickly; the agreement must state a separate delivery/backlog objective if one is required. 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 Publish must correspond to the documented durable acceptance point. Retries can duplicate downstream delivery, so consumers remain idempotent. Subscription activation must respect receiver consent and supported protocol rules. Filter policy, message attributes and FIFO behavior are limited by this target profile. Unsupported subscription or publish shapes are not implied by the numerical acceptance row.Example and diagnosis
For topicorder-created, publishing one 2 KiB event to ten subscriptions uses the single-publish row. The request can satisfy its SLA while an unreachable webhook accumulates retries; inspect delivery state separately. If adapter-owned outbox insertion is slow, that is fabric time rather than subscriber time and remains Tensor9’s responsibility.
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.
SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL
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
Forgoogle::1.0.0::cloudsql::postgresql, Publish persists accepted notifications and per-subscription delivery work in a PostgreSQL outbox. Workers deliver later and record their result. The latency row ends at API acceptance, not successful receipt by every subscriber.
How the latency targets were chosen
Bounded notification acceptance: 20 ms monthly p99.Publish. The PostgreSQL path persists per-subscriber delivery work; native brokers fan out differently. Adapter subscription/authorization/outbox work stays on the fabric clock.
Bounded notification batch acceptance: 50 ms monthly p99. PublishBatch. Batch decoding, target calls and delivery scheduling are bounded by both entries and fan-out.
Topic and subscription configuration: 20 ms monthly p99. ConfirmSubscription, CreateTopic, DeleteTopic, GetSubscriptionAttributes, GetTopicAttributes, ListTagsForResource, SetSubscriptionAttributes, SetTopicAttributes, Subscribe, TagResource, Unsubscribe, UntagResource. Configuration and authorization state must be persisted; waiting for a human or endpoint confirmation is not promised within this request-response budget.
Bounded topic and subscription pages: 20 ms monthly p99. ListSubscriptions, ListSubscriptionsByTopic, ListTopics. Persistent catalog reads and token/result generation are included.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Bound subscriptions per topic, filter complexity, payload bytes and queued deliveries as well as publish rate. A publish with 20 subscribers creates up to 20 units of delivery work. Scale request handlers and delivery workers independently, and watch outbox age or broker backlog. Subscriber timeouts and provider quotas can limit delivery even when the adapter accepts new work quickly; the agreement must state a separate delivery/backlog objective if one is required. 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 Publish must correspond to the documented durable acceptance point. Retries can duplicate downstream delivery, so consumers remain idempotent. Subscription activation must respect receiver consent and supported protocol rules. Filter policy, message attributes and FIFO behavior are limited by this target profile. Unsupported subscription or publish shapes are not implied by the numerical acceptance row.Example and diagnosis
For topicorder-created, publishing one 2 KiB event to ten subscriptions uses the single-publish row. The request can satisfy its SLA while an unreachable webhook accumulates retries; inspect delivery state separately. If adapter-owned outbox insertion is slow, that is fabric time rather than subscriber time and remains Tensor9’s responsibility.
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.
SNS (Simple Notification Service) to Google Cloud Pub/Sub
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
Forgoogle::1.0.0::pubsub, Publish maps to the native topic service, while adapter workers can pull broker subscriptions and forward notifications to the configured destination. Native topic acceptance and final HTTP/SQS/email delivery are different events; the request SLA covers the first adapter interaction.
How the latency targets were chosen
Bounded notification acceptance: 3 ms monthly p99.Publish. The PostgreSQL path persists per-subscriber delivery work; native brokers fan out differently. Adapter subscription/authorization/outbox work stays on the fabric clock.
Bounded notification batch acceptance: 10 ms monthly p99. PublishBatch. Batch decoding, target calls and delivery scheduling are bounded by both entries and fan-out.
Topic and subscription configuration: 20 ms monthly p99. ConfirmSubscription, CreateTopic, DeleteTopic, GetSubscriptionAttributes, GetTopicAttributes, ListTagsForResource, SetSubscriptionAttributes, SetTopicAttributes, Subscribe, TagResource, Unsubscribe, UntagResource. Configuration and authorization state must be persisted; waiting for a human or endpoint confirmation is not promised within this request-response budget.
Bounded topic and subscription pages: 20 ms monthly p99. ListSubscriptions, ListSubscriptionsByTopic, ListTopics. Persistent catalog reads and token/result generation are included.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Bound subscriptions per topic, filter complexity, payload bytes and queued deliveries as well as publish rate. A publish with 20 subscribers creates up to 20 units of delivery work. Scale request handlers and delivery workers independently, and watch outbox age or broker backlog. Subscriber timeouts and provider quotas can limit delivery even when the adapter accepts new work quickly; the agreement must state a separate delivery/backlog objective if one is required. 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 Publish must correspond to the documented durable acceptance point. Retries can duplicate downstream delivery, so consumers remain idempotent. Subscription activation must respect receiver consent and supported protocol rules. Filter policy, message attributes and FIFO behavior are limited by this target profile. Unsupported subscription or publish shapes are not implied by the numerical acceptance row.Example and diagnosis
For topicorder-created, publishing one 2 KiB event to ten subscriptions uses the single-publish row. The request can satisfy its SLA while an unreachable webhook accumulates retries; inspect delivery state separately. If adapter-owned outbox insertion is slow, that is fabric time rather than subscriber time and remains Tensor9’s responsibility.
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.
SNS (Simple Notification Service) to PostgreSQL
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
Forpostgres::1.0.0::database, Publish persists accepted notifications and per-subscription delivery work in a PostgreSQL outbox. Workers deliver later and record their result. The latency row ends at API acceptance, not successful receipt by every subscriber.
How the latency targets were chosen
Bounded notification acceptance: 20 ms monthly p99.Publish. The PostgreSQL path persists per-subscriber delivery work; native brokers fan out differently. Adapter subscription/authorization/outbox work stays on the fabric clock.
Bounded notification batch acceptance: 50 ms monthly p99. PublishBatch. Batch decoding, target calls and delivery scheduling are bounded by both entries and fan-out.
Topic and subscription configuration: 20 ms monthly p99. ConfirmSubscription, CreateTopic, DeleteTopic, GetSubscriptionAttributes, GetTopicAttributes, ListTagsForResource, SetSubscriptionAttributes, SetTopicAttributes, Subscribe, TagResource, Unsubscribe, UntagResource. Configuration and authorization state must be persisted; waiting for a human or endpoint confirmation is not promised within this request-response budget.
Bounded topic and subscription pages: 20 ms monthly p99. ListSubscriptions, ListSubscriptionsByTopic, ListTopics. Persistent catalog reads and token/result generation are included.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Bound subscriptions per topic, filter complexity, payload bytes and queued deliveries as well as publish rate. A publish with 20 subscribers creates up to 20 units of delivery work. Scale request handlers and delivery workers independently, and watch outbox age or broker backlog. Subscriber timeouts and provider quotas can limit delivery even when the adapter accepts new work quickly; the agreement must state a separate delivery/backlog objective if one is required. 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 Publish must correspond to the documented durable acceptance point. Retries can duplicate downstream delivery, so consumers remain idempotent. Subscription activation must respect receiver consent and supported protocol rules. Filter policy, message attributes and FIFO behavior are limited by this target profile. Unsupported subscription or publish shapes are not implied by the numerical acceptance row.Example and diagnosis
For topicorder-created, publishing one 2 KiB event to ten subscriptions uses the single-publish row. The request can satisfy its SLA while an unreachable webhook accumulates retries; inspect delivery state separately. If adapter-owned outbox insertion is slow, that is fabric time rather than subscriber time and remains Tensor9’s responsibility.
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. SetT9_API_KEY as described in Install and Authenticate, then list the adapters your account may use with this origin: