Service Adapter SLAs

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.

Each terms row is one standard service level. A pending row means no standard numerical term has been assigned to that directed adapter; it does not inherit another adapter’s target. Follow the adapter link for covered operations, request limits and examples. Monthly p99 means 99% of covered requests in the month must meet the stated latency target. 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. See the measurement rules for how adapter time is measured. Notes apply to all SLA rows for that adapter. On this page

Amazon Web Services

Amazon Web Services

Origin service	Adapter	SLA	Service level	Conditions	Notes
ACM (certificates)	ACM Certificate to Certificate Manager	Pending	No numerical term	Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.
ACM (certificates)	ACM Certificate to Key Vault	Pending	No numerical term	Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.
ACM (certificates)	ACM Certificate to cert-manager Certificate	Pending	No numerical term	Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.
API Gateway (REST)	API Gateway (REST) to Envoy	API Gateway authoring reads adapter-added latency	+5 ms monthly p99	Point read or at most 100 returned records; configuration at most 1 MiB. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing.	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. Deployment availability. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing.
API Gateway (REST)	API Gateway (REST) to Envoy	API, route, integration and authorizer mutation adapter-added latency	+12 ms monthly p99	One resource per call; API configuration at most 1 MiB. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing.	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.
API Gateway (REST)	API Gateway (REST) to Envoy	Deployment and stage coordination adapter-added latency	+25 ms monthly p99	at most 100 routes and at most 20 authorizers/integrations; provider propagation separate. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
API Gateway (REST)	API Gateway (REST) to Envoy	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A deployment is an immutable complete revision, stages select one revision atomically, dependent routes never become public when an authorizer is removed, and invocation authority remains separate from caller authority. Unsupported private links or custom-domain shapes fail explicitly.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
API Gateway (REST)	API Gateway (REST) to Envoy	Endpoint reachability	99.9% per calendar month	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. These targets apply only to a deployed API Gateway REST adapter on Envoy named in a signed agreement. Envoy packet forwarding and integrated function execution are separate from management-request processing.
API Gateway (REST)	API Gateway (REST) to Envoy	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Azure API Management	API Gateway authoring reads adapter-added latency	+5 ms monthly p99	Point read or at most 100 returned records; configuration at most 1 MiB.	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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Azure API Management	API, route, integration and authorizer mutation adapter-added latency	+12 ms monthly p99	One resource per call; API configuration at most 1 MiB.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Azure API Management	Deployment and stage coordination adapter-added latency	+25 ms monthly p99	at most 100 routes and at most 20 authorizers/integrations; provider propagation 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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Azure API Management	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A deployment is an immutable complete revision, stages select one revision atomically, dependent routes never become public when an authorizer is removed, and invocation authority remains separate from caller authority. Unsupported private links or custom-domain shapes fail explicitly.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Azure API Management	Endpoint reachability	99.9% per calendar month	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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Azure API Management	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Envoy	WebSocket connection management adapter-added latency	+5 ms monthly p99	One owned connection and at most 32 KiB posted data; client receipt is not implied.	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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Envoy	API Gateway authoring reads adapter-added latency	+5 ms monthly p99	Point read or at most 100 returned records; configuration at most 1 MiB.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Envoy	API, route, integration and authorizer mutation adapter-added latency	+12 ms monthly p99	One resource per call; API configuration at most 1 MiB.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Envoy	Deployment and stage coordination adapter-added latency	+25 ms monthly p99	at most 100 routes and at most 20 authorizers/integrations; provider propagation 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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Envoy	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A deployment is an immutable complete revision, stages select one revision atomically, dependent routes never become public when an authorizer is removed, and invocation authority remains separate from caller authority. Unsupported private links or custom-domain shapes fail explicitly.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Envoy	Endpoint reachability	99.9% per calendar month	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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Envoy	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway	API Gateway authoring reads adapter-added latency	+5 ms monthly p99	Point read or at most 100 returned records; configuration at most 1 MiB.	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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway	API, route, integration and authorizer mutation adapter-added latency	+12 ms monthly p99	One resource per call; API configuration at most 1 MiB.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway	Deployment and stage coordination adapter-added latency	+25 ms monthly p99	at most 100 routes and at most 20 authorizers/integrations; provider propagation 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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A deployment is an immutable complete revision, stages select one revision atomically, dependent routes never become public when an authorizer is removed, and invocation authority remains separate from caller authority. Unsupported private links or custom-domain shapes fail explicitly.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway	Endpoint reachability	99.9% per calendar month	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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Google Cloud API Gateway	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
API Gateway v2 (HTTP/WebSocket)	API Gateway v2 (HTTP/WebSocket) to Tensor9 Trivial	Not applicable	No numerical term	The application or appliance ingress supplies this routing capability; there is no API Gateway adapter endpoint to measure for this mapping.
AWS Organizations	AWS Organizations to Organization account store	Bounded account listing adapter-added latency	+8 ms monthly p99	At most 100 accounts in the entire backing account store and 1 MiB serialized output; authorization, full-store scan and serialization included. No pagination is provided. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability.	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. Deployment availability. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability.
AWS Organizations	AWS Organizations to Organization account store	Organization creation adapter-added latency	+15 ms monthly p99	One authenticated management account, one organization and a 64 KiB request; durable commit included. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability.	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.
AWS Organizations	AWS Organizations to Organization account store	Account lifecycle transaction adapter-added latency	+40 ms monthly p99	One account and at most 20 linked identity/claim records; host-owned transaction and durable response included, external provisioning readiness excluded. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
AWS Organizations	AWS Organizations to Organization account store	Documented adapter behavior	Preserve the supported behavior documented for this adapter	CreateOrganization must bind the verified caller. CreateAccount may succeed only when bootstrap authority and the host transaction are available; retries preserve account identity. CloseAccount must not retire a foreign member. DescribeOrganization is deliberately unserved, not a hidden implication of the shared model.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
AWS Organizations	AWS Organizations to Organization account store	Endpoint reachability	99.9% per calendar month	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. These targets apply only to a deployed, authenticated Organizations account-plane endpoint with the account-lifecycle transaction available and the operations named in a signed agreement. A numerical target does not establish deployment availability.
AWS Organizations	AWS Organizations to Organization account store	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
AppConfig	AppConfig to Azure App Configuration	Not applicable	No numerical term	Configuration is seeded during deployment and read through the target’s native SDK. There is no AppConfig request-serving adapter on this path.
Application Load Balancer	Application Load Balancer to Azure Load Balancer	Network and load-balancer state reads adapter-added latency	+8 ms monthly p99	One resource or at most 100 returned listeners, targets or rules.	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.
Application Load Balancer	Application Load Balancer to Azure Load Balancer	Listener, target and topology mutation adapter-added latency	+18 ms monthly p99	One load balancer/network; at most 20 listeners and at most 100 targets; readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Application Load Balancer	Application Load Balancer to Azure Load Balancer	Bounded routing and authorization policy adapter-added latency	+25 ms monthly p99	at most 100 routing rules, at most 20 conditions per rule and at most 20 target groups.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Application Load Balancer	Application Load Balancer to Azure Load Balancer	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.
Application Load Balancer	Application Load Balancer to Azure Load Balancer	Endpoint reachability	99.9% per calendar month	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.
Application Load Balancer	Application Load Balancer to Azure Load Balancer	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Application Load Balancer	Application Load Balancer to Cloud Load Balancing	Network and load-balancer state reads adapter-added latency	+8 ms monthly p99	One resource or at most 100 returned listeners, targets or rules.	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.
Application Load Balancer	Application Load Balancer to Cloud Load Balancing	Listener, target and topology mutation adapter-added latency	+18 ms monthly p99	One load balancer/network; at most 20 listeners and at most 100 targets; readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Application Load Balancer	Application Load Balancer to Cloud Load Balancing	Bounded routing and authorization policy adapter-added latency	+25 ms monthly p99	at most 100 routing rules, at most 20 conditions per rule and at most 20 target groups.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Application Load Balancer	Application Load Balancer to Cloud Load Balancing	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.
Application Load Balancer	Application Load Balancer to Cloud Load Balancing	Endpoint reachability	99.9% per calendar month	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.
Application Load Balancer	Application Load Balancer to Cloud Load Balancing	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Application Load Balancer	Application Load Balancer to OCI Load Balancer	Network and load-balancer state reads adapter-added latency	+8 ms monthly p99	One resource or at most 100 returned listeners, targets or rules.	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.
Application Load Balancer	Application Load Balancer to OCI Load Balancer	Listener, target and topology mutation adapter-added latency	+18 ms monthly p99	One load balancer/network; at most 20 listeners and at most 100 targets; readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Application Load Balancer	Application Load Balancer to OCI Load Balancer	Bounded routing and authorization policy adapter-added latency	+25 ms monthly p99	at most 100 routing rules, at most 20 conditions per rule and at most 20 target groups.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Application Load Balancer	Application Load Balancer to OCI Load Balancer	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.
Application Load Balancer	Application Load Balancer to OCI Load Balancer	Endpoint reachability	99.9% per calendar month	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.
Application Load Balancer	Application Load Balancer to OCI Load Balancer	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Application Load Balancer	Application Load Balancer to Scaleway Load Balancer	Not applicable	No numerical term	This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider’s networking terms apply.
Aurora PostgreSQL	Aurora PostgreSQL to AlloyDB for PostgreSQL	Bounded cluster and member status adapter-added latency	+20 ms monthly p99	One cluster or at most 100 adapter-owned cluster/member records and 256 KiB response; observed target status included, PostgreSQL query time excluded. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here.	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. Deployment availability. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here.
Aurora PostgreSQL	Aurora PostgreSQL to AlloyDB for PostgreSQL	Cluster and member lifecycle admission adapter-added latency	+30 ms monthly p99	One cluster or member and at most 32 KiB supported settings; validation and durable intent included, AlloyDB provisioning, failover and teardown readiness excluded. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here.	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.
Aurora PostgreSQL	Aurora PostgreSQL to AlloyDB for PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle call means complete desired state is durable, not that AlloyDB is ready. The adapter preserves the Aurora cluster/member relationship and writer-versus-reader identities, refuses unsupported Aurora settings, and never reports a foreign database as adapter-managed. Status reflects observed target readiness rather than an optimistic synthetic success.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Aurora PostgreSQL	Aurora PostgreSQL to AlloyDB for PostgreSQL	Endpoint reachability	99.9% per calendar month	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. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Aurora PostgreSQL	Aurora PostgreSQL to AlloyDB for PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Aurora PostgreSQL	Aurora PostgreSQL to AlloyDB for PostgreSQL (RDS proxy)	Bounded cluster and member status adapter-added latency	+20 ms monthly p99	One cluster or at most 100 adapter-owned cluster/member records and 256 KiB response; observed target status included, PostgreSQL query time excluded. The Aurora PostgreSQL-to-AlloyDB backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here.	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. Deployment availability. The Aurora PostgreSQL-to-AlloyDB backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here.
Aurora PostgreSQL	Aurora PostgreSQL to AlloyDB for PostgreSQL (RDS proxy)	Cluster and member lifecycle admission adapter-added latency	+30 ms monthly p99	One cluster or member and at most 32 KiB supported settings; validation and durable intent included, AlloyDB provisioning, failover and teardown readiness excluded. The Aurora PostgreSQL-to-AlloyDB backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here.	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.
Aurora PostgreSQL	Aurora PostgreSQL to AlloyDB for PostgreSQL (RDS proxy)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle call means complete desired state is durable, not that AlloyDB is ready. The adapter preserves the Aurora cluster/member relationship and writer-versus-reader identities, refuses unsupported Aurora settings, and never reports a foreign database as adapter-managed. Status reflects observed target readiness rather than an optimistic synthetic success.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Aurora PostgreSQL	Aurora PostgreSQL to AlloyDB for PostgreSQL (RDS proxy)	Endpoint reachability	99.9% per calendar month	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. The Aurora PostgreSQL-to-AlloyDB backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Aurora PostgreSQL	Aurora PostgreSQL to AlloyDB for PostgreSQL (RDS proxy)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Aurora PostgreSQL	Aurora PostgreSQL to Cloud SQL for PostgreSQL	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
Aurora PostgreSQL	Aurora PostgreSQL to Cloud SQL for PostgreSQL	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Aurora PostgreSQL	Aurora PostgreSQL to Cloud SQL for PostgreSQL	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Aurora PostgreSQL	Aurora PostgreSQL to Cloud SQL for PostgreSQL	Bounded Data API translation adapter-added latency	+5 ms monthly p99	One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work.	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.
Aurora PostgreSQL	Aurora PostgreSQL to Cloud SQL for PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
Aurora PostgreSQL	Aurora PostgreSQL to Cloud SQL for PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
Aurora PostgreSQL	Aurora PostgreSQL to Cloud SQL for PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Aurora PostgreSQL	Aurora PostgreSQL to OCI Database with PostgreSQL	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
Aurora PostgreSQL	Aurora PostgreSQL to OCI Database with PostgreSQL	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Aurora PostgreSQL	Aurora PostgreSQL to OCI Database with PostgreSQL	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Aurora PostgreSQL	Aurora PostgreSQL to OCI Database with PostgreSQL	Bounded Data API translation adapter-added latency	+5 ms monthly p99	One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work.	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.
Aurora PostgreSQL	Aurora PostgreSQL to OCI Database with PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
Aurora PostgreSQL	Aurora PostgreSQL to OCI Database with PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
Aurora PostgreSQL	Aurora PostgreSQL to OCI Database with PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL (CloudNativePG)	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL (CloudNativePG)	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL (CloudNativePG)	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL (CloudNativePG)	Bounded Data API translation adapter-added latency	+5 ms monthly p99	One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work.	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.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL (CloudNativePG)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL (CloudNativePG)	Endpoint reachability	99.9% per calendar month	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.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL (CloudNativePG)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL Flexible Server	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL Flexible Server	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL Flexible Server	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL Flexible Server	Bounded Data API translation adapter-added latency	+5 ms monthly p99	One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work.	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.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL Flexible Server	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL Flexible Server	Endpoint reachability	99.9% per calendar month	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.
Aurora PostgreSQL	Aurora PostgreSQL to PostgreSQL Flexible Server	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Aurora PostgreSQL	Aurora PostgreSQL to Scaleway Managed Database for PostgreSQL	Not applicable	No numerical term	This mapping provisions a native database. SQL clients connect directly to it; this directed mapping does not expose an RDS management adapter endpoint. Database availability and query latency are covered by the database provider, not a Tensor9 request-processing SLA.
DynamoDB	DynamoDB to Azure Cosmos DB (provisioned)	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to Azure Cosmos DB (provisioned)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to Azure Cosmos DB (provisioned)	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to Azure Cosmos DB (provisioned)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Small point reads adapter-added latency	+1 ms monthly p99	One complete item at most 4 KiB, at most 64 attributes and nesting depth 8; covered read-consistency and DynamoDB ProjectionExpression settings. Selecting fewer attributes does not reduce the full-item size used for this limit. No implicit follow-up page.	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.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Plain small-item writes adapter-added latency	+1 ms monthly p99	One complete item at most 4 KiB; no condition, ReturnValues absent or NONE, no streams and no secondary-index maintenance. A composite profile row is restricted to these plain-write shapes.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Conditional writes and updates adapter-added latency	+5 ms monthly p99	One item at most 4 KiB, expression at most 2 KiB with at most 20 clauses; at most two maintained indexes. The agreement must name any stream-enabled variant. Local retries and adapter metadata waits count.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Bounded query and scan pages adapter-added latency	+10 ms monthly p99	One page; at most 100 items examined, each at most 4 KiB, at most 400 KiB decoded in total. The cap is on examined items, not only returned matches; residual filtering counts.	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.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Bounded item batches adapter-added latency	+10 ms monthly p99	At most 25 item actions and 100 KiB aggregate full-item data. Per-item results and unprocessed-item behavior follow this backend’s profile.	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.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Bounded PartiQL statements adapter-added latency	+10 ms monthly p99	At most 10 statements of 2 KiB each; at most 100 examined items or 400 KiB returned/decoded data. Only grammar and transaction forms supported by this target are covered.	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.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	DynamoDB Streams reads adapter-added latency	+10 ms monthly p99	One stream page, at most 100 records and 400 KiB total record data; a single shard iterator and the documented retention window.	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.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Endpoint reachability	99.9% per calendar month	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.
DynamoDB	DynamoDB to Azure Cosmos DB (serverless)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to Cloud Bigtable	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to Cloud Bigtable	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to Cloud Bigtable	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to Cloud Bigtable	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to Cloud Bigtable	Small point reads adapter-added latency	+1 ms monthly p99	One complete item at most 4 KiB, at most 64 attributes and nesting depth 8; covered read-consistency and DynamoDB ProjectionExpression settings. Selecting fewer attributes does not reduce the full-item size used for this limit. No implicit follow-up page.	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.
DynamoDB	DynamoDB to Cloud Bigtable	Plain small-item writes adapter-added latency	+1 ms monthly p99	One complete item at most 4 KiB; no condition, ReturnValues absent or NONE, no streams and no secondary-index maintenance. A composite profile row is restricted to these plain-write shapes.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to Cloud Bigtable	Conditional writes and updates adapter-added latency	+3 ms monthly p99	One item at most 4 KiB, expression at most 2 KiB with at most 20 clauses; at most two maintained indexes. The agreement must name any stream-enabled variant. Local retries and adapter metadata waits count.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to Cloud Bigtable	Bounded query and scan pages adapter-added latency	+5 ms monthly p99	One page; at most 100 items examined, each at most 4 KiB, at most 400 KiB decoded in total. The cap is on examined items, not only returned matches; residual filtering counts.	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.
DynamoDB	DynamoDB to Cloud Bigtable	Bounded item batches adapter-added latency	+10 ms monthly p99	At most 25 item actions and 100 KiB aggregate full-item data. Per-item results and unprocessed-item behavior follow this backend’s profile.	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.
DynamoDB	DynamoDB to Cloud Bigtable	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to Cloud Bigtable	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.
DynamoDB	DynamoDB to Cloud Bigtable	Endpoint reachability	99.9% per calendar month	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.
DynamoDB	DynamoDB to Cloud Bigtable	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Small point reads adapter-added latency	+1 ms monthly p99	One complete item at most 4 KiB, at most 64 attributes and nesting depth 8; covered read-consistency and DynamoDB ProjectionExpression settings. Selecting fewer attributes does not reduce the full-item size used for this limit. No implicit follow-up page.	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Plain small-item writes adapter-added latency	+1 ms monthly p99	One complete item at most 4 KiB; no condition, ReturnValues absent or NONE, no streams and no secondary-index maintenance. A composite profile row is restricted to these plain-write shapes.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Conditional writes and updates adapter-added latency	+3 ms monthly p99	One item at most 4 KiB, expression at most 2 KiB with at most 20 clauses; at most two maintained indexes. The agreement must name any stream-enabled variant. Local retries and adapter metadata waits count.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Bounded query and scan pages adapter-added latency	+5 ms monthly p99	One page; at most 100 items examined, each at most 4 KiB, at most 400 KiB decoded in total. The cap is on examined items, not only returned matches; residual filtering counts.	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Bounded item batches adapter-added latency	+10 ms monthly p99	At most 25 item actions and 100 KiB aggregate full-item data. Per-item results and unprocessed-item behavior follow this backend’s profile.	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Bounded transactions adapter-added latency	+10 ms monthly p99	At most 10 actions and 40 KiB total item data, at most two tables, within the target’s documented transaction scope. This row does not add transaction support to a profile that rejects it.	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Bounded PartiQL statements adapter-added latency	+10 ms monthly p99	At most 10 statements of 2 KiB each; at most 100 examined items or 400 KiB returned/decoded data. Only grammar and transaction forms supported by this target are covered.	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	DynamoDB Streams reads adapter-added latency	+10 ms monthly p99	One stream page, at most 100 records and 400 KiB total record data; a single shard iterator and the documented retention window.	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
DynamoDB	DynamoDB to Cloud SQL for PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to Cloud Spanner	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to Cloud Spanner	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to Cloud Spanner	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to Cloud Spanner	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to Firestore	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to Firestore	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to Firestore	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to Firestore	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to Firestore	Endpoint reachability	99.9% per calendar month	Tests whether the endpoint can be reached, separately from whether requests complete correctly.	What Tensor9 covers. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results.
DynamoDB	DynamoDB to Firestore	GetItem, plain PutItem / DeleteItem adapter-added latency	+1 ms monthly p99	Full item ≤4 KiB, at most 64 attributes and nesting depth 8. Covered read-consistency settings. Writes have no condition, ReturnValues absent/NONE, no secondary-index maintenance, and streams disabled.	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. DynamoDB write limits. A plain write has no `ConditionExpression` or legacy `Expected`, no returned old item (`ReturnValues` absent or `NONE`), and streams disabled. The index configuration must be covered by your agreement. Size limits include the full current item and any previous item the adapter must read. For a delete that does not read the old item, count the key and request size. Writes with streams enabled need a separate latency agreement. Table management, PartiQL and Streams operations are not covered here. Any smaller API limit still applies.
DynamoDB	DynamoDB to Firestore	UpdateItem, conditional or old-item-return PutItem / DeleteItem adapter-added latency	+3 ms monthly p99	Full item ≤4 KiB; expression ≤2 KiB and at most 20 clauses; at most two maintained indexes; streams disabled. Use supported conditions and return-value options. Local retries and adapter metadata waits count.	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. Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA.
DynamoDB	DynamoDB to Firestore	Query, Scan adapter-added latency	+10 ms monthly p99	One page. The adapter may examine or load ≤100 items and ≤400 KiB of data, including items filtered out of the response.	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. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.
DynamoDB	DynamoDB to Firestore	TransactWriteItems adapter-added latency	+20 ms monthly p99	Supported combinations of operations, with ≤100 actions and ≤400 KiB of total data. Any smaller API or adapter limit still applies.	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.
DynamoDB	DynamoDB to Firestore	Saving writes without losing data	Save all required data before returning success	Save both the backend data and required adapter records before returning success. The adapter must not lose data it has confirmed as saved.
DynamoDB	DynamoDB to Firestore	Conditions, transactions and stored values	Preserve the behavior documented for this adapter	Apply each condition check and write together. Preserve supported all-or-nothing transactions, number values, and read/index behavior. The supported item-size limit remains 400 KiB.
DynamoDB	DynamoDB to Firestore	Adapter autoscaling and limits	Automatic scaling within agreed traffic and deployment limits	Agree limits for the mix of operations, full item and expression sizes, indexes, heavily used documents, which process writes stream records, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Backend capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits.
DynamoDB	DynamoDB to OCI NoSQL Database	Not applicable	No numerical term	The mapping provisions OCI NoSQL tables without exposing a DynamoDB management endpoint. There is no DynamoDB request-serving fabric on this path.
DynamoDB	DynamoDB to OCI NoSQL Database	Not applicable	No numerical term	The application uses the OCI NoSQL API on this mapping. It does not provide a DynamoDB request translator, so DynamoDB fabric latency does not apply.
DynamoDB	DynamoDB to PostgreSQL	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to PostgreSQL	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to PostgreSQL	Small point reads adapter-added latency	+1 ms monthly p99	One complete item at most 4 KiB, at most 64 attributes and nesting depth 8; covered read-consistency and DynamoDB ProjectionExpression settings. Selecting fewer attributes does not reduce the full-item size used for this limit. No implicit follow-up page.	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.
DynamoDB	DynamoDB to PostgreSQL	Plain small-item writes adapter-added latency	+1 ms monthly p99	One complete item at most 4 KiB; no condition, ReturnValues absent or NONE, no streams and no secondary-index maintenance. A composite profile row is restricted to these plain-write shapes.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
DynamoDB	DynamoDB to PostgreSQL	Conditional writes and updates adapter-added latency	+3 ms monthly p99	One item at most 4 KiB, expression at most 2 KiB with at most 20 clauses; at most two maintained indexes. The agreement must name any stream-enabled variant. Local retries and adapter metadata waits count.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
DynamoDB	DynamoDB to PostgreSQL	Bounded query and scan pages adapter-added latency	+5 ms monthly p99	One page; at most 100 items examined, each at most 4 KiB, at most 400 KiB decoded in total. The cap is on examined items, not only returned matches; residual filtering counts.	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.
DynamoDB	DynamoDB to PostgreSQL	Bounded item batches adapter-added latency	+10 ms monthly p99	At most 25 item actions and 100 KiB aggregate full-item data. Per-item results and unprocessed-item behavior follow this backend’s profile.	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.
DynamoDB	DynamoDB to PostgreSQL	Bounded transactions adapter-added latency	+10 ms monthly p99	At most 10 actions and 40 KiB total item data, at most two tables, within the target’s documented transaction scope. This row does not add transaction support to a profile that rejects it.	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.
DynamoDB	DynamoDB to PostgreSQL	Bounded PartiQL statements adapter-added latency	+10 ms monthly p99	At most 10 statements of 2 KiB each; at most 100 examined items or 400 KiB returned/decoded data. Only grammar and transaction forms supported by this target are covered.	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.
DynamoDB	DynamoDB to PostgreSQL	DynamoDB Streams reads adapter-added latency	+10 ms monthly p99	One stream page, at most 100 records and 400 KiB total record data; a single shard iterator and the documented retention window.	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.
DynamoDB	DynamoDB to PostgreSQL	Table and configuration API responses adapter-added latency	+20 ms monthly p99	One logical table, at most 20 attributes and two declared indexes, or a list page of at most 100 tables. Measures request handling and status response, not the time until target DDL, backup, restore or index build finishes.	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.
DynamoDB	DynamoDB to PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.
DynamoDB	DynamoDB to PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
DynamoDB	DynamoDB to PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
DynamoDB	DynamoDB to Provisioned Cosmos DB	Endpoint reachability	99.9% per calendar month	Tests whether the endpoint can be reached, separately from whether requests complete correctly.	What Tensor9 covers. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results.
DynamoDB	DynamoDB to Provisioned Cosmos DB	GetItem, plain PutItem / DeleteItem adapter-added latency	+1 ms monthly p99	Full item ≤4 KiB, at most 64 attributes and nesting depth 8. Covered read-consistency settings. Writes have no condition, ReturnValues absent/NONE, no secondary-index maintenance, and streams disabled.	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. DynamoDB write limits. A plain write has no `ConditionExpression` or legacy `Expected`, no returned old item (`ReturnValues` absent or `NONE`), and streams disabled. The index configuration must be covered by your agreement. Size limits include the full current item and any previous item the adapter must read. For a delete that does not read the old item, count the key and request size. Writes with streams enabled need a separate latency agreement. Table management, PartiQL and Streams operations are not covered here. Any smaller API limit still applies.
DynamoDB	DynamoDB to Provisioned Cosmos DB	UpdateItem, conditional or old-item-return PutItem / DeleteItem adapter-added latency	+5 ms monthly p99	Full item ≤4 KiB; expression ≤2 KiB and at most 20 clauses; at most two maintained indexes; streams disabled. Use supported conditions and return-value options. Local retries and adapter metadata waits count.	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. Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA.
DynamoDB	DynamoDB to Provisioned Cosmos DB	Query, Scan adapter-added latency	+10 ms monthly p99	One page. The adapter may examine or load ≤100 items and ≤400 KiB of data, including items filtered out of the response.	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. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.
DynamoDB	DynamoDB to Provisioned Cosmos DB	BatchGetItem, BatchWriteItem adapter-added latency	+20 ms monthly p99	≤100 items and ≤400 KiB of total data. Any smaller API limit still applies. Report items that were not processed.	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.
DynamoDB	DynamoDB to Provisioned Cosmos DB	Saving each write completely	Save all required data before returning success	Save each write within its partition together with required metadata and records for pending follow-up work. Apply supported condition checks and writes together. No multi-item transaction SLA.
DynamoDB	DynamoDB to Provisioned Cosmos DB	Base-table and index consistency	Read consistency as documented for this adapter	Use a Strong-consistency Cosmos DB account for strongly consistent table and local secondary index reads. Global secondary indexes update asynchronously, with no fixed freshness deadline. Strongly consistent GSI requests are rejected.
DynamoDB	DynamoDB to Provisioned Cosmos DB	Adapter autoscaling and limits	Automatic scaling within agreed traffic and deployment limits	Agree limits for the mix of operations, full item and expression sizes, indexes and streams, Cosmos DB throughput mode (RU/s), partition and container layout, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Backend capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits.
DynamoDB	DynamoDB to Spanner	Endpoint reachability	99.9% per calendar month	Tests whether the endpoint can be reached, separately from whether requests complete correctly.	What Tensor9 covers. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results.
DynamoDB	DynamoDB to Spanner	GetItem adapter-added latency	+1 ms monthly p99	Full item ≤4 KiB. Use the read-consistency and index settings covered by your agreement.	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. DynamoDB write limits. A plain write has no `ConditionExpression` or legacy `Expected`, no returned old item (`ReturnValues` absent or `NONE`), and streams disabled. The index configuration must be covered by your agreement. Size limits include the full current item and any previous item the adapter must read. For a delete that does not read the old item, count the key and request size. Writes with streams enabled need a separate latency agreement. Table management, PartiQL and Streams operations are not covered here. Any smaller API limit still applies.
DynamoDB	DynamoDB to Spanner	Plain PutItem / DeleteItem adapter-added latency	+1 ms monthly p99	Full item ≤4 KiB, at most 64 attributes and nesting depth 8. Covered read-consistency settings. Writes have no condition, ReturnValues absent/NONE, no secondary-index maintenance, and streams disabled.	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. Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA.
DynamoDB	DynamoDB to Spanner	UpdateItem, conditional or old-item-return PutItem / DeleteItem adapter-added latency	+3 ms monthly p99	Full item ≤4 KiB; expression ≤2 KiB and at most 20 clauses; at most two maintained indexes; streams disabled. Use supported conditions and return-value options. Local retries and adapter metadata waits count.	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. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.
DynamoDB	DynamoDB to Spanner	Query, Scan adapter-added latency	+5 ms monthly p99	One page. The adapter may examine or load ≤100 items and ≤400 KiB of data, including items filtered out of the response.	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.
DynamoDB	DynamoDB to Spanner	BatchGetItem, BatchWriteItem adapter-added latency	+20 ms monthly p99	≤100 items and ≤400 KiB of total data. Any smaller API limit still applies. Report items that were not processed.	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.
DynamoDB	DynamoDB to Spanner	TransactGetItems, TransactWriteItems adapter-added latency	+20 ms monthly p99	Supported combinations of operations, with ≤100 actions and ≤400 KiB of total data. Any smaller API or adapter limit still applies.	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.
DynamoDB	DynamoDB to Spanner	Saving writes without losing data	Save all required data before returning success	Save both the backend data and required adapter records before returning success. Recovering adapter records must not lose data already confirmed as saved.
DynamoDB	DynamoDB to Spanner	Transactions, reads and stored values	Preserve the behavior documented for this adapter	Transactions must be all-or-nothing and safe to retry as documented. Preserve exact decimals and strongly consistent table reads; update indexes with the transaction. Strongly consistent GSI reads are unsupported.
DynamoDB	DynamoDB to Spanner	Adapter autoscaling and limits	Automatic scaling within agreed traffic and deployment limits	Agree limits for the mix of operations, full item and transaction sizes, indexes, total connections and sessions, heavily used rows, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Backend capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits.
EC2	EC2 Instances to Compute Engine	Pending	No numerical term	Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.
EC2	EC2 Instances to Compute Instance	Pending	No numerical term	Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.
EC2	EC2 Instances to KubeVirt VM	Pending	No numerical term	Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.
EC2	EC2 Instances to Scaleway Instance	Instance and volume lifecycle admission adapter-added latency	+20 ms monthly p99	at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness 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.
EC2	EC2 Instances to Scaleway Instance	Documented adapter behavior	Preserve the supported behavior documented for this adapter	IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EC2	EC2 Instances to Scaleway Instance	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EC2	EC2 Instances to Scaleway Instance	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EC2	EC2 Instances to Virtual Machines	Pending	No numerical term	Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.
EC2 Auto Scaling	EC2 Auto Scaling to Managed Instance Group	Fleet configuration and identity reads adapter-added latency	+5 ms monthly p99	One fleet; at most 20 zones/templates and at most 100 instances in returned status.	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.
EC2 Auto Scaling	EC2 Auto Scaling to Managed Instance Group	Fleet and scaling-policy mutation adapter-added latency	+20 ms monthly p99	One fleet and at most 20 policies/hooks; instance readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EC2 Auto Scaling	EC2 Auto Scaling to Managed Instance Group	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Minimum, maximum and desired capacity remain ordered and bounded. A successful mutation is durable, stale reconciliation cannot overwrite a newer generation, and target policy translation cannot silently change the metric or threshold. Replacement and drain preserve the declared availability policy.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EC2 Auto Scaling	EC2 Auto Scaling to Managed Instance Group	Endpoint reachability	99.9% per calendar month	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.
EC2 Auto Scaling	EC2 Auto Scaling to Managed Instance Group	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EC2 Auto Scaling	EC2 Auto Scaling to Virtual Machine Scale Sets	Fleet configuration and identity reads adapter-added latency	+5 ms monthly p99	One fleet; at most 20 zones/templates and at most 100 instances in returned status.	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.
EC2 Auto Scaling	EC2 Auto Scaling to Virtual Machine Scale Sets	Fleet and scaling-policy mutation adapter-added latency	+20 ms monthly p99	One fleet and at most 20 policies/hooks; instance readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EC2 Auto Scaling	EC2 Auto Scaling to Virtual Machine Scale Sets	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Minimum, maximum and desired capacity remain ordered and bounded. A successful mutation is durable, stale reconciliation cannot overwrite a newer generation, and target policy translation cannot silently change the metric or threshold. Replacement and drain preserve the declared availability policy.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EC2 Auto Scaling	EC2 Auto Scaling to Virtual Machine Scale Sets	Endpoint reachability	99.9% per calendar month	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.
EC2 Auto Scaling	EC2 Auto Scaling to Virtual Machine Scale Sets	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EC2 Control Plane	EC2 Control Plane to Compute Engine	Bounded self and fleet resource reads adapter-added latency	+10 ms monthly p99	at most 100 returned resources and at most 20 filters.	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.
EC2 Control Plane	EC2 Control Plane to Compute Engine	Instance and volume lifecycle admission adapter-added latency	+20 ms monthly p99	at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EC2 Control Plane	EC2 Control Plane to Compute Engine	Documented adapter behavior	Preserve the supported behavior documented for this adapter	IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EC2 Control Plane	EC2 Control Plane to Compute Engine	Endpoint reachability	99.9% per calendar month	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.
EC2 Control Plane	EC2 Control Plane to Compute Engine	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EC2 Control Plane	EC2 Control Plane to Virtual Machines	Bounded self and fleet resource reads adapter-added latency	+10 ms monthly p99	at most 100 returned resources and at most 20 filters.	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.
EC2 Control Plane	EC2 Control Plane to Virtual Machines	Instance and volume lifecycle admission adapter-added latency	+20 ms monthly p99	at most 20 resources/tags per call; image/volume payload not transferred through adapter; readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EC2 Control Plane	EC2 Control Plane to Virtual Machines	Documented adapter behavior	Preserve the supported behavior documented for this adapter	IMDS and describe responses identify the same instance, network and attached resources. Lifecycle success means desired state is durably recorded, IDs are stable, foreign resources are not exposed, and unsupported mutation forms fail before partial target changes.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EC2 Control Plane	EC2 Control Plane to Virtual Machines	Endpoint reachability	99.9% per calendar month	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.
EC2 Control Plane	EC2 Control Plane to Virtual Machines	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
ECS	ECS Cluster to Kubernetes Cluster	Cluster and workload desired-state admission adapter-added latency	+20 ms monthly p99	One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness 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.
ECS	ECS Cluster to Kubernetes Cluster	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
ECS	ECS Cluster to Kubernetes Cluster	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
ECS	ECS Cluster to Kubernetes Cluster	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EKS	EKS Cluster to AKS Cluster	Cluster, workload and identity reads adapter-added latency	+8 ms monthly p99	One point read or at most 100 returned resources; manifest/status at most 1 MiB.	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.
EKS	EKS Cluster to AKS Cluster	Cluster and workload desired-state admission adapter-added latency	+20 ms monthly p99	One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EKS	EKS Cluster to AKS Cluster	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EKS	EKS Cluster to AKS Cluster	Endpoint reachability	99.9% per calendar month	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.
EKS	EKS Cluster to AKS Cluster	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EKS	EKS Cluster to GKE Cluster	Cluster, workload and identity reads adapter-added latency	+8 ms monthly p99	One point read or at most 100 returned resources; manifest/status at most 1 MiB.	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.
EKS	EKS Cluster to GKE Cluster	Cluster and workload desired-state admission adapter-added latency	+20 ms monthly p99	One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EKS	EKS Cluster to GKE Cluster	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EKS	EKS Cluster to GKE Cluster	Endpoint reachability	99.9% per calendar month	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.
EKS	EKS Cluster to GKE Cluster	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EKS	EKS Cluster to Kubernetes Cluster	Not applicable	No numerical term	Applications use the target cluster’s Kubernetes API directly. This mapping does not expose an EKS management adapter endpoint. Kubernetes API availability and pod scheduling are not measured as service-adapter request latency.
EKS	EKS Cluster to OKE Cluster	Cluster, workload and identity reads adapter-added latency	+8 ms monthly p99	One point read or at most 100 returned resources; manifest/status at most 1 MiB.	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.
EKS	EKS Cluster to OKE Cluster	Cluster and workload desired-state admission adapter-added latency	+20 ms monthly p99	One cluster/service/task definition; at most 20 containers and at most 100 environment/secret/network entries; readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EKS	EKS Cluster to OKE Cluster	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EKS	EKS Cluster to OKE Cluster	Endpoint reachability	99.9% per calendar month	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.
EKS	EKS Cluster to OKE Cluster	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
ElastiCache	ElastiCache to Azure Managed Redis	Bounded cache status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 replication groups, member clusters or subnet groups, or the tags of one resource, and at most 256 KiB of response. Reports the recorded configuration and observed target status; it is not a Redis command latency commitment.	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.
ElastiCache	ElastiCache to Azure Managed Redis	Cache lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One replication group, subnet group or tag change with at most 32 KiB of settings and 50 tags. Measures validation and durable request acceptance, not the elapsed time to create or delete the target cache or its proxy.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
ElastiCache	ElastiCache to Azure Managed Redis	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
ElastiCache	ElastiCache to Azure Managed Redis	Endpoint reachability	99.9% per calendar month	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.
ElastiCache	ElastiCache to Azure Managed Redis	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
ElastiCache	ElastiCache to Bitnami Valkey	Bounded cache status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 replication groups, member clusters or subnet groups, or the tags of one resource, and at most 256 KiB of response. Reports the recorded configuration and observed target status; it is not a Redis command latency commitment.	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.
ElastiCache	ElastiCache to Bitnami Valkey	Cache lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One replication group, subnet group or tag change with at most 32 KiB of settings and 50 tags. Measures validation and durable request acceptance, not the elapsed time to create or delete the target cache or its proxy.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
ElastiCache	ElastiCache to Bitnami Valkey	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
ElastiCache	ElastiCache to Bitnami Valkey	Endpoint reachability	99.9% per calendar month	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.
ElastiCache	ElastiCache to Bitnami Valkey	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
ElastiCache	ElastiCache to Dragonfly	Bounded cache status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 replication groups, member clusters or subnet groups, or the tags of one resource, and at most 256 KiB of response. Reports the recorded configuration and observed target status; it is not a Redis command latency commitment.	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.
ElastiCache	ElastiCache to Dragonfly	Cache lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One replication group, subnet group or tag change with at most 32 KiB of settings and 50 tags. Measures validation and durable request acceptance, not the elapsed time to create or delete the target cache or its proxy.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
ElastiCache	ElastiCache to Dragonfly	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
ElastiCache	ElastiCache to Dragonfly	Endpoint reachability	99.9% per calendar month	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.
ElastiCache	ElastiCache to Dragonfly	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
ElastiCache	ElastiCache to Memorystore for Redis	Bounded cache status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 replication groups, member clusters or subnet groups, or the tags of one resource, and at most 256 KiB of response. Reports the recorded configuration and observed target status; it is not a Redis command latency commitment.	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.
ElastiCache	ElastiCache to Memorystore for Redis	Cache lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One replication group, subnet group or tag change with at most 32 KiB of settings and 50 tags. Measures validation and durable request acceptance, not the elapsed time to create or delete the target cache or its proxy.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
ElastiCache	ElastiCache to Memorystore for Redis	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
ElastiCache	ElastiCache to Memorystore for Redis	Endpoint reachability	99.9% per calendar month	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.
ElastiCache	ElastiCache to Memorystore for Redis	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
ElastiCache	ElastiCache to OCI Cache	Bounded cache status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 replication groups, member clusters or subnet groups, or the tags of one resource, and at most 256 KiB of response. Reports the recorded configuration and observed target status; it is not a Redis command latency commitment.	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.
ElastiCache	ElastiCache to OCI Cache	Cache lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One replication group, subnet group or tag change with at most 32 KiB of settings and 50 tags. Measures validation and durable request acceptance, not the elapsed time to create or delete the target cache or its proxy.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
ElastiCache	ElastiCache to OCI Cache	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
ElastiCache	ElastiCache to OCI Cache	Endpoint reachability	99.9% per calendar month	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.
ElastiCache	ElastiCache to OCI Cache	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EventBridge	EventBridge to Azure Event Grid	Not applicable	No numerical term	This mapping uses native Event Grid delivery rather than an EventBridge API endpoint. Event delivery follows the target service’s behavior; there is no EventBridge adapter request to measure.
EventBridge	EventBridge to Cloud SQL for PostgreSQL	Bounded event acceptance and matching adapter-added latency	+25 ms monthly p99	At most 10 events and 40 KiB aggregate detail; at most 20 enabled rules per bus, 20 clauses per pattern and five targets per matching rule. Measures PutEvents acceptance, not destination completion.	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.
EventBridge	EventBridge to Cloud SQL for PostgreSQL	Bus, rule and target configuration adapter-added latency	+20 ms monthly p99	One bus or rule, at most five targets and 32 KiB configuration, or a page of at most 100 records. Supported schedule syntax only; configuration response latency is not scheduled firing accuracy.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EventBridge	EventBridge to Cloud SQL for PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	PutEvents must retain per-entry failure reporting. Accepted delivery work must survive an adapter restart according to the documented durable-store design. A destination can receive duplicates if it accepts a call just before the worker loses its acknowledgement. Input selection, pattern matching, target permissions and schedule syntax must follow the profile. The latency row does not promise exactly-once delivery, arbitrary cron precision or end-to-end delivery within 25 ms.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EventBridge	EventBridge to Cloud SQL for PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
EventBridge	EventBridge to Cloud SQL for PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EventBridge	EventBridge to Container Apps	Not applicable	No numerical term	Scheduled jobs run as Container Apps jobs. This mapping does not expose an event bus or a PutEvents adapter endpoint; job execution is not fabric request latency.
EventBridge	EventBridge to PostgreSQL	Bounded event acceptance and matching adapter-added latency	+25 ms monthly p99	At most 10 events and 40 KiB aggregate detail; at most 20 enabled rules per bus, 20 clauses per pattern and five targets per matching rule. Measures PutEvents acceptance, not destination completion.	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.
EventBridge	EventBridge to PostgreSQL	Bus, rule and target configuration adapter-added latency	+20 ms monthly p99	One bus or rule, at most five targets and 32 KiB configuration, or a page of at most 100 records. Supported schedule syntax only; configuration response latency is not scheduled firing accuracy.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EventBridge	EventBridge to PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	PutEvents must retain per-entry failure reporting. Accepted delivery work must survive an adapter restart according to the documented durable-store design. A destination can receive duplicates if it accepts a call just before the worker loses its acknowledgement. Input selection, pattern matching, target permissions and schedule syntax must follow the profile. The latency row does not promise exactly-once delivery, arbitrary cron precision or end-to-end delivery within 25 ms.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EventBridge	EventBridge to PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
EventBridge	EventBridge to PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EventBridge	EventBridge to PostgreSQL Flexible Server	Bounded event acceptance and matching adapter-added latency	+25 ms monthly p99	At most 10 events and 40 KiB aggregate detail; at most 20 enabled rules per bus, 20 clauses per pattern and five targets per matching rule. Measures PutEvents acceptance, not destination completion.	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.
EventBridge	EventBridge to PostgreSQL Flexible Server	Bus, rule and target configuration adapter-added latency	+20 ms monthly p99	One bus or rule, at most five targets and 32 KiB configuration, or a page of at most 100 records. Supported schedule syntax only; configuration response latency is not scheduled firing accuracy.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
EventBridge	EventBridge to PostgreSQL Flexible Server	Documented adapter behavior	Preserve the supported behavior documented for this adapter	PutEvents must retain per-entry failure reporting. Accepted delivery work must survive an adapter restart according to the documented durable-store design. A destination can receive duplicates if it accepts a call just before the worker loses its acknowledgement. Input selection, pattern matching, target permissions and schedule syntax must follow the profile. The latency row does not promise exactly-once delivery, arbitrary cron precision or end-to-end delivery within 25 ms.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
EventBridge	EventBridge to PostgreSQL Flexible Server	Endpoint reachability	99.9% per calendar month	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.
EventBridge	EventBridge to PostgreSQL Flexible Server	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
EventBridge	EventBridge to Pub/Sub	Not applicable	No numerical term	This mapping uses native Pub/Sub delivery rather than an EventBridge API endpoint. Event delivery follows the target service’s behavior; there is no EventBridge adapter request to measure.
IAM	IAM to Cedar	Endpoint reachability	99.9% per calendar month	Tests whether the covered IAM, STS and authorization services can be reached, separately from whether they handle requests correctly.	What Tensor9 covers. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results.
IAM	IAM to Cedar	Time for an in-adapter permission check	5 ms monthly p99	Request context ≤4 KiB; ≤1,000 relevant policies and ≤1,000 entities; total policy/entity data ≤1 MiB. Policy complexity must stay within the limits in your agreement.	Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA.
IAM	IAM to Cedar	Administration adapter-added latency	+20 ms monthly p99	Only the 50 listed IAM operations. Request ≤16 KiB; response ≤64 KiB; each list page ≤100 entries.	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. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.
IAM	IAM to Cedar	GetCallerIdentity, AssumeRole, AssumeRoleWithWebIdentity adapter-added latency	+50 ms monthly p99	Request/input token ≤16 KiB. Use supported request options and token formats.	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.
IAM	IAM to Cedar	Authorization correctness	Never grant access because a check failed or is unsupported	An explicit deny overrides an allow; no matching allow means deny. Respect role/session permissions and expiry. Correct denials are successful checks; missing usable policies are failures.
IAM	IAM to Cedar	Saving and applying policy updates	Save policies durably before confirming success	Check a complete policy update before installing it. Each adapter must switch to the full update at once, without mixing old and new policies.
IAM	IAM to Cedar	Distributing policy updates	Updates reach other adapters, but no fixed deadline is promised	No fixed deadline for every adapter to receive a policy change or revoke access. One health check or Explain report cannot confirm that all adapters have updated.
IAM	IAM to Cedar	Adapter autoscaling and limits	Automatic scaling within agreed traffic and deployment limits	Set separate limits for completed IAM operations, STS operations and authorization checks. Include policy/entity complexity, readiness to serve requests, policy-update traffic, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Backend capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits.
KMS	KMS Keys to Cloud KMS	Cryptographic operations adapter-added latency	+5 ms monthly p99	Input at most 64 KiB, at most 20 encryption-context entries, one key; provider crypto time separately spanned.	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.
KMS	KMS Keys to Cloud KMS	Key metadata and bounded lists adapter-added latency	+8 ms monthly p99	at most 100 returned entries; policy at most 32 KiB.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
KMS	KMS Keys to Cloud KMS	Key, alias, policy and grant mutation adapter-added latency	+15 ms monthly p99	One key/alias/grant; at most 50 tags and grants; policy at most 32 KiB.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
KMS	KMS Keys to Cloud KMS	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter never substitutes a key, drops encryption context, returns plaintext to an unauthorized principal or acknowledges key-policy state before it is durable. Disabled and pending-deletion keys fail closed. Unsupported asymmetric, HMAC, import or multi-region shapes fail explicitly on profiles that do not cover them.
KMS	KMS Keys to Cloud KMS	Endpoint reachability	99.9% per calendar month	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.
KMS	KMS Keys to Cloud KMS	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
KMS	KMS Keys to Key Vault	Cryptographic operations adapter-added latency	+5 ms monthly p99	Input at most 64 KiB, at most 20 encryption-context entries, one key; provider crypto time separately spanned.	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.
KMS	KMS Keys to Key Vault	Key metadata and bounded lists adapter-added latency	+8 ms monthly p99	at most 100 returned entries; policy at most 32 KiB.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
KMS	KMS Keys to Key Vault	Key, alias, policy and grant mutation adapter-added latency	+15 ms monthly p99	One key/alias/grant; at most 50 tags and grants; policy at most 32 KiB.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
KMS	KMS Keys to Key Vault	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter never substitutes a key, drops encryption context, returns plaintext to an unauthorized principal or acknowledges key-policy state before it is durable. Disabled and pending-deletion keys fail closed. Unsupported asymmetric, HMAC, import or multi-region shapes fail explicitly on profiles that do not cover them.
KMS	KMS Keys to Key Vault	Endpoint reachability	99.9% per calendar month	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.
KMS	KMS Keys to Key Vault	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Kinesis Data Firehose	Kinesis Data Firehose to Azure Event Hubs	Small delivery-record acceptance adapter-added latency	+3 ms monthly p99	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.	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.
Kinesis Data Firehose	Kinesis Data Firehose to Azure Event Hubs	Bounded delivery-record batch acceptance adapter-added latency	+10 ms monthly p99	At most 100 records and 400 KiB aggregate decoded data. Each record’s result is preserved. Destination transformation and scheduled flush completion 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Kinesis Data Firehose	Kinesis Data Firehose to Azure Event Hubs	Delivery-stream configuration responses adapter-added latency	+20 ms monthly p99	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.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Kinesis Data Firehose	Kinesis Data Firehose to Azure Event Hubs	Documented adapter behavior	Preserve the supported behavior documented for this adapter	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.
Kinesis Data Firehose	Kinesis Data Firehose to Azure Event Hubs	Endpoint reachability	99.9% per calendar month	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.
Kinesis Data Firehose	Kinesis Data Firehose to Azure Event Hubs	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Kinesis Data Firehose	Kinesis Data Firehose to OCI Streaming	Small delivery-record acceptance adapter-added latency	+3 ms monthly p99	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.	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.
Kinesis Data Firehose	Kinesis Data Firehose to OCI Streaming	Bounded delivery-record batch acceptance adapter-added latency	+10 ms monthly p99	At most 100 records and 400 KiB aggregate decoded data. Each record’s result is preserved. Destination transformation and scheduled flush completion 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Kinesis Data Firehose	Kinesis Data Firehose to OCI Streaming	Delivery-stream configuration responses adapter-added latency	+20 ms monthly p99	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.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Kinesis Data Firehose	Kinesis Data Firehose to OCI Streaming	Documented adapter behavior	Preserve the supported behavior documented for this adapter	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.
Kinesis Data Firehose	Kinesis Data Firehose to OCI Streaming	Endpoint reachability	99.9% per calendar month	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.
Kinesis Data Firehose	Kinesis Data Firehose to OCI Streaming	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Kinesis Data Firehose	Kinesis Data Firehose to Pub/Sub	Small delivery-record acceptance adapter-added latency	+3 ms monthly p99	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.	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.
Kinesis Data Firehose	Kinesis Data Firehose to Pub/Sub	Bounded delivery-record batch acceptance adapter-added latency	+10 ms monthly p99	At most 100 records and 400 KiB aggregate decoded data. Each record’s result is preserved. Destination transformation and scheduled flush completion 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Kinesis Data Firehose	Kinesis Data Firehose to Pub/Sub	Delivery-stream configuration responses adapter-added latency	+20 ms monthly p99	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.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Kinesis Data Firehose	Kinesis Data Firehose to Pub/Sub	Documented adapter behavior	Preserve the supported behavior documented for this adapter	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.
Kinesis Data Firehose	Kinesis Data Firehose to Pub/Sub	Endpoint reachability	99.9% per calendar month	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.
Kinesis Data Firehose	Kinesis Data Firehose to Pub/Sub	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Kinesis Data Firehose	Kinesis Data Firehose to Strimzi Kafka	Small delivery-record acceptance adapter-added latency	+3 ms monthly p99	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.	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.
Kinesis Data Firehose	Kinesis Data Firehose to Strimzi Kafka	Bounded delivery-record batch acceptance adapter-added latency	+10 ms monthly p99	At most 100 records and 400 KiB aggregate decoded data. Each record’s result is preserved. Destination transformation and scheduled flush completion 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Kinesis Data Firehose	Kinesis Data Firehose to Strimzi Kafka	Delivery-stream configuration responses adapter-added latency	+20 ms monthly p99	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.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Kinesis Data Firehose	Kinesis Data Firehose to Strimzi Kafka	Documented adapter behavior	Preserve the supported behavior documented for this adapter	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.
Kinesis Data Firehose	Kinesis Data Firehose to Strimzi Kafka	Endpoint reachability	99.9% per calendar month	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.
Kinesis Data Firehose	Kinesis Data Firehose to Strimzi Kafka	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Kinesis Data Stream	Kinesis Data Stream to Azure Event Hubs	Small record append and iterator requests adapter-added latency	+3 ms monthly p99	One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class.	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.
Kinesis Data Stream	Kinesis Data Stream to Azure Event Hubs	Bounded record batch and read page adapter-added latency	+10 ms monthly p99	At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Kinesis Data Stream	Kinesis Data Stream to Azure Event Hubs	Stream configuration requests adapter-added latency	+20 ms monthly p99	One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Kinesis Data Stream	Kinesis Data Stream to Azure Event Hubs	Documented adapter behavior	Preserve the supported behavior documented for this adapter	For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.
Kinesis Data Stream	Kinesis Data Stream to Azure Event Hubs	Endpoint reachability	99.9% per calendar month	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.
Kinesis Data Stream	Kinesis Data Stream to Azure Event Hubs	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Kinesis Data Stream	Kinesis Data Stream to Managed Service for Apache Kafka	Small record append and iterator requests adapter-added latency	+3 ms monthly p99	One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class.	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.
Kinesis Data Stream	Kinesis Data Stream to Managed Service for Apache Kafka	Bounded record batch and read page adapter-added latency	+10 ms monthly p99	At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Kinesis Data Stream	Kinesis Data Stream to Managed Service for Apache Kafka	Stream configuration requests adapter-added latency	+20 ms monthly p99	One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Kinesis Data Stream	Kinesis Data Stream to Managed Service for Apache Kafka	Documented adapter behavior	Preserve the supported behavior documented for this adapter	For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.
Kinesis Data Stream	Kinesis Data Stream to Managed Service for Apache Kafka	Endpoint reachability	99.9% per calendar month	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.
Kinesis Data Stream	Kinesis Data Stream to Managed Service for Apache Kafka	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Kinesis Data Stream	Kinesis Data Stream to OCI Streaming	Small record append and iterator requests adapter-added latency	+3 ms monthly p99	One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class.	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.
Kinesis Data Stream	Kinesis Data Stream to OCI Streaming	Bounded record batch and read page adapter-added latency	+10 ms monthly p99	At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Kinesis Data Stream	Kinesis Data Stream to OCI Streaming	Stream configuration requests adapter-added latency	+20 ms monthly p99	One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Kinesis Data Stream	Kinesis Data Stream to OCI Streaming	Documented adapter behavior	Preserve the supported behavior documented for this adapter	For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.
Kinesis Data Stream	Kinesis Data Stream to OCI Streaming	Endpoint reachability	99.9% per calendar month	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.
Kinesis Data Stream	Kinesis Data Stream to OCI Streaming	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Kinesis Data Stream	Kinesis Data Stream to Pub/Sub	Small record append and iterator requests adapter-added latency	+3 ms monthly p99	One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class.	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.
Kinesis Data Stream	Kinesis Data Stream to Pub/Sub	Bounded record batch and read page adapter-added latency	+10 ms monthly p99	At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Kinesis Data Stream	Kinesis Data Stream to Pub/Sub	Stream configuration requests adapter-added latency	+20 ms monthly p99	One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Kinesis Data Stream	Kinesis Data Stream to Pub/Sub	Documented adapter behavior	Preserve the supported behavior documented for this adapter	For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.
Kinesis Data Stream	Kinesis Data Stream to Pub/Sub	Endpoint reachability	99.9% per calendar month	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.
Kinesis Data Stream	Kinesis Data Stream to Pub/Sub	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Kinesis Data Stream	Kinesis Data Stream to Strimzi Kafka	Small record append and iterator requests adapter-added latency	+3 ms monthly p99	One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class.	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.
Kinesis Data Stream	Kinesis Data Stream to Strimzi Kafka	Bounded record batch and read page adapter-added latency	+10 ms monthly p99	At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Kinesis Data Stream	Kinesis Data Stream to Strimzi Kafka	Stream configuration requests adapter-added latency	+20 ms monthly p99	One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Kinesis Data Stream	Kinesis Data Stream to Strimzi Kafka	Documented adapter behavior	Preserve the supported behavior documented for this adapter	For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.
Kinesis Data Stream	Kinesis Data Stream to Strimzi Kafka	Endpoint reachability	99.9% per calendar month	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.
Kinesis Data Stream	Kinesis Data Stream to Strimzi Kafka	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Lambda	Lambda Function to AKS function Deployments	Unary function invocation translation adapter-added latency	+5 ms monthly p99	Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget.	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.
Lambda	Lambda Function to AKS function Deployments	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Lambda	Lambda Function to AKS function Deployments	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Lambda	Lambda Function to AKS function Deployments	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Lambda	Lambda Function to Azure Container Apps	Unary function invocation translation adapter-added latency	+5 ms monthly p99	Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget.	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.
Lambda	Lambda Function to Azure Container Apps	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Lambda	Lambda Function to Azure Container Apps	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Lambda	Lambda Function to Azure Container Apps	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Lambda	Lambda Function to Azure Functions (Flex Consumption)	Unary function invocation translation adapter-added latency	+5 ms monthly p99	Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget.	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.
Lambda	Lambda Function to Azure Functions (Flex Consumption)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Lambda	Lambda Function to Azure Functions (Flex Consumption)	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Lambda	Lambda Function to Azure Functions (Flex Consumption)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Lambda	Lambda Function to Azure Functions (Premium)	Unary function invocation translation adapter-added latency	+5 ms monthly p99	Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget.	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.
Lambda	Lambda Function to Azure Functions (Premium)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Lambda	Lambda Function to Azure Functions (Premium)	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Lambda	Lambda Function to Azure Functions (Premium)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Lambda	Lambda Function to Cloud Run	Unary function invocation translation adapter-added latency	+5 ms monthly p99	Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget.	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.
Lambda	Lambda Function to Cloud Run	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Lambda	Lambda Function to Cloud Run	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Lambda	Lambda Function to Cloud Run	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Lambda	Lambda Function to Knative Service	Unary function invocation translation adapter-added latency	+5 ms monthly p99	Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget.	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.
Lambda	Lambda Function to Knative Service	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Lambda	Lambda Function to Knative Service	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Lambda	Lambda Function to Knative Service	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Lambda	Lambda Function to Kubernetes Cluster	Unary function invocation translation adapter-added latency	+5 ms monthly p99	Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget.	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.
Lambda	Lambda Function to Kubernetes Cluster	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Lambda	Lambda Function to Kubernetes Cluster	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Lambda	Lambda Function to Kubernetes Cluster	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Lambda	Lambda Function to OCI Functions	Unary function invocation translation adapter-added latency	+5 ms monthly p99	Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget.	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.
Lambda	Lambda Function to OCI Functions	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Lambda	Lambda Function to OCI Functions	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Lambda	Lambda Function to OCI Functions	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Lambda	Lambda Function to OKE function Deployments	Unary function invocation translation adapter-added latency	+5 ms monthly p99	Request and response each at most 64 KiB; function execution separately spanned; larger bodies use a separately qualified byte-throughput budget.	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.
Lambda	Lambda Function to OKE function Deployments	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter invokes the selected function/version with the caller and integration authority the profile specifies. Payload and status are preserved, streaming order is stable, retries do not duplicate an acknowledged synchronous result, and unsupported event-source mappings fail explicitly.	How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Lambda	Lambda Function to OKE function Deployments	Endpoint reachability	99.9% per calendar month	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.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Lambda	Lambda Function to OKE function Deployments	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Network Load Balancer	Network Load Balancer to Azure Load Balancer	Network and load-balancer state reads adapter-added latency	+8 ms monthly p99	One resource or at most 100 returned listeners, targets or rules.	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.
Network Load Balancer	Network Load Balancer to Azure Load Balancer	Listener, target and topology mutation adapter-added latency	+18 ms monthly p99	One load balancer/network; at most 20 listeners and at most 100 targets; readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Network Load Balancer	Network Load Balancer to Azure Load Balancer	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Network Load Balancer	Network Load Balancer to Azure Load Balancer	Endpoint reachability	99.9% per calendar month	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.
Network Load Balancer	Network Load Balancer to Azure Load Balancer	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Network Load Balancer	Network Load Balancer to Cloud Load Balancing	Pending	No numerical term	Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.
Network Load Balancer	Network Load Balancer to OCI Network Load Balancer	Network and load-balancer state reads adapter-added latency	+8 ms monthly p99	One resource or at most 100 returned listeners, targets or rules.	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.
Network Load Balancer	Network Load Balancer to OCI Network Load Balancer	Listener, target and topology mutation adapter-added latency	+18 ms monthly p99	One load balancer/network; at most 20 listeners and at most 100 targets; readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Network Load Balancer	Network Load Balancer to OCI Network Load Balancer	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Network Load Balancer	Network Load Balancer to OCI Network Load Balancer	Endpoint reachability	99.9% per calendar month	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.
Network Load Balancer	Network Load Balancer to OCI Network Load Balancer	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Network Load Balancer	Network Load Balancer to Scaleway Load Balancer	Not applicable	No numerical term	This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider’s networking terms apply.
RDS MySQL	RDS MySQL to Cloud SQL for MySQL	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
RDS MySQL	RDS MySQL to Cloud SQL for MySQL	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
RDS MySQL	RDS MySQL to Cloud SQL for MySQL	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
RDS MySQL	RDS MySQL to Cloud SQL for MySQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
RDS MySQL	RDS MySQL to Cloud SQL for MySQL	Endpoint reachability	99.9% per calendar month	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.
RDS MySQL	RDS MySQL to Cloud SQL for MySQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
RDS MySQL	RDS MySQL to MySQL Flexible Server	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
RDS MySQL	RDS MySQL to MySQL Flexible Server	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
RDS MySQL	RDS MySQL to MySQL Flexible Server	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
RDS MySQL	RDS MySQL to MySQL Flexible Server	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
RDS MySQL	RDS MySQL to MySQL Flexible Server	Endpoint reachability	99.9% per calendar month	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.
RDS MySQL	RDS MySQL to MySQL Flexible Server	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
RDS MySQL	RDS MySQL to OCI MySQL Database (HeatWave)	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
RDS MySQL	RDS MySQL to OCI MySQL Database (HeatWave)	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
RDS MySQL	RDS MySQL to OCI MySQL Database (HeatWave)	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
RDS MySQL	RDS MySQL to OCI MySQL Database (HeatWave)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
RDS MySQL	RDS MySQL to OCI MySQL Database (HeatWave)	Endpoint reachability	99.9% per calendar month	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.
RDS MySQL	RDS MySQL to OCI MySQL Database (HeatWave)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
RDS MySQL	RDS MySQL to Percona XtraDB Cluster (MySQL)	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
RDS MySQL	RDS MySQL to Percona XtraDB Cluster (MySQL)	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
RDS MySQL	RDS MySQL to Percona XtraDB Cluster (MySQL)	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
RDS MySQL	RDS MySQL to Percona XtraDB Cluster (MySQL)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
RDS MySQL	RDS MySQL to Percona XtraDB Cluster (MySQL)	Endpoint reachability	99.9% per calendar month	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.
RDS MySQL	RDS MySQL to Percona XtraDB Cluster (MySQL)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
RDS MySQL	RDS MySQL to Scaleway Managed Database for MySQL	Not applicable	No numerical term	This mapping provisions a native database. SQL clients connect directly to it; this directed mapping does not expose an RDS management adapter endpoint. Database availability and query latency are covered by the database provider, not a Tensor9 request-processing SLA.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL (RDS proxy)	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. The RDS PostgreSQL-to-Cloud SQL backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. It is composed only by sipsvr’s Docker deployment with a configured database proxy. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here.	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. Deployment availability. The RDS PostgreSQL-to-Cloud SQL backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. It is composed only by sipsvr’s Docker deployment with a configured database proxy. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL (RDS proxy)	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. The RDS PostgreSQL-to-Cloud SQL backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. It is composed only by sipsvr’s Docker deployment with a configured database proxy. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here.	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.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL (RDS proxy)	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. The RDS PostgreSQL-to-Cloud SQL backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. It is composed only by sipsvr’s Docker deployment with a configured database proxy. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL (RDS proxy)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL (RDS proxy)	Endpoint reachability	99.9% per calendar month	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. The RDS PostgreSQL-to-Cloud SQL backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. It is composed only by sipsvr’s Docker deployment with a configured database proxy. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here.
RDS PostgreSQL	RDS PostgreSQL to Cloud SQL for PostgreSQL (RDS proxy)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
RDS PostgreSQL	RDS PostgreSQL to OCI Database with PostgreSQL	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
RDS PostgreSQL	RDS PostgreSQL to OCI Database with PostgreSQL	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
RDS PostgreSQL	RDS PostgreSQL to OCI Database with PostgreSQL	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
RDS PostgreSQL	RDS PostgreSQL to OCI Database with PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
RDS PostgreSQL	RDS PostgreSQL to OCI Database with PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
RDS PostgreSQL	RDS PostgreSQL to OCI Database with PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL (CloudNativePG)	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL (CloudNativePG)	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL (CloudNativePG)	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL (CloudNativePG)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL (CloudNativePG)	Endpoint reachability	99.9% per calendar month	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.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL (CloudNativePG)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL Flexible Server	Bounded database status responses adapter-added latency	+20 ms monthly p99	One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment.	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.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL Flexible Server	Database lifecycle request acceptance adapter-added latency	+30 ms monthly p99	One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL Flexible Server	Bounded database parameter requests adapter-added latency	+20 ms monthly p99	One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL Flexible Server	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL Flexible Server	Endpoint reachability	99.9% per calendar month	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.
RDS PostgreSQL	RDS PostgreSQL to PostgreSQL Flexible Server	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
RDS PostgreSQL	RDS PostgreSQL to Scaleway Managed Database for PostgreSQL	Not applicable	No numerical term	This mapping provisions a native database. SQL clients connect directly to it; this directed mapping does not expose an RDS management adapter endpoint. Database availability and query latency are covered by the database provider, not a Tensor9 request-processing SLA.
Route 53	Route53 to Azure DNS	DNS management reads adapter-added latency	+8 ms monthly p99	One point read or at most 100 returned zones, records, checks, endpoints or rules.	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.
Route 53	Route53 to Azure DNS	Bounded zone and record mutation adapter-added latency	+20 ms monthly p99	One zone/check or at most 100 record changes and at most 1 MiB request; DNS propagation 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Route 53	Route53 to Azure DNS	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Route 53	Route53 to Azure DNS	Endpoint reachability	99.9% per calendar month	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.
Route 53	Route53 to Azure DNS	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Route 53	Route53 to Cloud DNS	DNS management reads adapter-added latency	+8 ms monthly p99	One point read or at most 100 returned zones, records, checks, endpoints or rules.	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.
Route 53	Route53 to Cloud DNS	Bounded zone and record mutation adapter-added latency	+20 ms monthly p99	One zone/check or at most 100 record changes and at most 1 MiB request; DNS propagation 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Route 53	Route53 to Cloud DNS	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Route 53	Route53 to Cloud DNS	Endpoint reachability	99.9% per calendar month	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.
Route 53	Route53 to Cloud DNS	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Route 53	Route53 to Cloudflare DNS	DNS management reads adapter-added latency	+8 ms monthly p99	One point read or at most 100 returned zones, records, checks, endpoints or rules.	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.
Route 53	Route53 to Cloudflare DNS	Bounded zone and record mutation adapter-added latency	+20 ms monthly p99	One zone/check or at most 100 record changes and at most 1 MiB request; DNS propagation 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Route 53	Route53 to Cloudflare DNS	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Route 53	Route53 to Cloudflare DNS	Endpoint reachability	99.9% per calendar month	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.
Route 53	Route53 to Cloudflare DNS	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Route 53	Route53 to OCI DNS	DNS management reads adapter-added latency	+8 ms monthly p99	One point read or at most 100 returned zones, records, checks, endpoints or rules.	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.
Route 53	Route53 to OCI DNS	Bounded zone and record mutation adapter-added latency	+20 ms monthly p99	One zone/check or at most 100 record changes and at most 1 MiB request; DNS propagation 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Route 53	Route53 to OCI DNS	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Route 53	Route53 to OCI DNS	Endpoint reachability	99.9% per calendar month	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.
Route 53	Route53 to OCI DNS	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Route 53	Route53 to Route 53 (any cloud)	DNS management reads adapter-added latency	+8 ms monthly p99	One point read or at most 100 returned zones, records, checks, endpoints or rules.	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.
Route 53	Route53 to Route 53 (any cloud)	Bounded zone and record mutation adapter-added latency	+20 ms monthly p99	One zone/check or at most 100 record changes and at most 1 MiB request; DNS propagation 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Route 53	Route53 to Route 53 (any cloud)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Route 53	Route53 to Route 53 (any cloud)	Endpoint reachability	99.9% per calendar month	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.
Route 53	Route53 to Route 53 (any cloud)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Route 53	Route53 to Scaleway Domains and DNS	Not applicable	No numerical term	DNS zones and records are provisioned through the target provider. This mapping has no Route 53 management adapter endpoint, and DNS lookups go directly to the provider’s name servers.
S3	S3 to Azure Blob Storage	Endpoint reachability	99.9% per calendar month	Tests whether the endpoint can be reached, separately from whether requests complete correctly.	What Tensor9 covers. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results.
S3	S3 to Azure Blob Storage	GetObject, PutObject adapter-added latency	+1 ms monthly p99	Object ≤64 KiB; request metadata ≤8 KiB; bucket versioning disabled. Count all bytes the adapter reads or transfers, not just those returned to the application. Version bookkeeping needs a separate class.	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. S3 operations without latency targets. These supported operations have no latency target here: `UploadPart`, `CopyObject`, `CreateMultipartUpload`, `AbortMultipartUpload`, `GetObjectTagging`, `PutObjectTagging`, `DeleteObjectTagging`, `CreateBucket`, `DeleteBucket` and `HeadBucket`. `ListMultipartUploads` and `UploadPartCopy` are not covered. Azure’s documented listing and version limits still apply; delimiter/`CommonPrefixes` requests are unsupported. A small range read must also fit the byte limit for all data the adapter reads or transfers.
S3	S3 to Azure Blob Storage	HeadObject, DeleteObject adapter-added latency	+1 ms monthly p99	Request and response metadata ≤8 KiB; delete targets an unversioned bucket and creates no delete marker. This limit does not restrict the stored object size.	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. Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA.
S3	S3 to Azure Blob Storage	ListObjects, ListObjectsV2, ListObjectVersions, ListParts adapter-added latency	+5 ms monthly p99	One page with ≤1,000 entries or parts and ≤1 MiB of response data. The adapter’s documented listing and version limits still apply.	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. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.
S3	S3 to Azure Blob Storage	DeleteObjects adapter-added latency	+20 ms monthly p99	≤1,000 keys. Record the result for each key, including failures.	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.
S3	S3 to Azure Blob Storage	CompleteMultipartUpload adapter-added latency	+20 ms monthly p99	≤1,000 parts. Measure the time Azure spends committing blocks separately.	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.
S3	S3 to Azure Blob Storage	Saving objects correctly	Save all required data before returning success	Keep object bytes, part order and required metadata intact. Reject unsupported request options and preserve the previous saved object if replacement fails. The provider’s own data-durability guarantee is separate.
S3	S3 to Azure Blob Storage	Adapter autoscaling and limits	Automatic scaling within agreed traffic and deployment limits	Agree limits for memory per request, bytes being transferred, copy bandwidth, work per object key, traffic growth and bursts, and spare capacity for failures. Adding adapter processes does not reduce the memory needed by one request. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Backend capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits.
S3	S3 to Google Cloud Storage	Endpoint reachability	99.9% per calendar month	Tests whether the endpoint can be reached, separately from whether requests complete correctly.	What Tensor9 covers. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results.
S3	S3 to Google Cloud Storage	GetObject, PutObject adapter-added latency	+1 ms monthly p99	Object ≤64 KiB; request metadata ≤8 KiB; bucket versioning disabled. Count all bytes the adapter reads or transfers, not just those returned to the application. Version bookkeeping needs a separate class.	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. S3 operations without latency targets. These supported operations have no latency target here: `UploadPart`, `CopyObject`, `CreateMultipartUpload`, `AbortMultipartUpload`, `GetObjectTagging`, `PutObjectTagging`, `DeleteObjectTagging`, `CreateBucket`, `DeleteBucket` and `HeadBucket`. `ListMultipartUploads` and `UploadPartCopy` are not covered. Azure’s documented listing and version limits still apply; delimiter/`CommonPrefixes` requests are unsupported. A small range read must also fit the byte limit for all data the adapter reads or transfers.
S3	S3 to Google Cloud Storage	HeadObject, DeleteObject adapter-added latency	+1 ms monthly p99	Request and response metadata ≤8 KiB; delete targets an unversioned bucket and creates no delete marker. This limit does not restrict the stored object size.	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. Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA.
S3	S3 to Google Cloud Storage	ListObjects, ListObjectsV2, ListObjectVersions, ListParts adapter-added latency	+5 ms monthly p99	One page with ≤1,000 entries or parts and ≤1 MiB of response data.	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. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.
S3	S3 to Google Cloud Storage	DeleteObjects adapter-added latency	+20 ms monthly p99	≤1,000 keys. Record the result for each key, including failures.	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.
S3	S3 to Google Cloud Storage	CompleteMultipartUpload adapter-added latency	+20 ms monthly p99	≤1,000 parts. Measure the time GCS spends combining parts separately.	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.
S3	S3 to Google Cloud Storage	Saving objects correctly	Save all required data before returning success	Keep object bytes, part order, required metadata and supported versions intact. A failed replacement must preserve the previous saved object. The provider’s own data-durability guarantee is separate.
S3	S3 to Google Cloud Storage	Adapter autoscaling and limits	Automatic scaling within agreed traffic and deployment limits	Agree limits for bytes, simultaneous transfers, backend calls per request, shared metadata work, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Backend capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits.
S3	S3 to MinIO Storage	Small object and metadata requests adapter-added latency	+1 ms monthly p99	One object; complete request and response bodies each at most 64 KiB, metadata at most 8 KiB. No archive restore or multipart completion. Larger streaming bodies need a byte-rate and completion budget in the agreement.	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.
S3	S3 to MinIO Storage	Object tagging adapter-added latency	+3 ms monthly p99	One object and at most 10 tags; total encoded tags at most 4 KiB. Only the tag characters and version-addressing forms listed by this target profile are covered.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
S3	S3 to MinIO Storage	Bounded object copy adapter-added latency	+3 ms monthly p99	One source and destination, object at most 64 KiB, metadata at most 8 KiB. Only supported source conditions and ranges are covered.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
S3	S3 to MinIO Storage	Bounded object and multipart listing adapter-added latency	+3 ms monthly p99	One page with at most 1,000 returned entries and 1 MiB of encoded response. No implicit traversal of later pages.	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.
S3	S3 to MinIO Storage	Bounded multi-object deletion adapter-added latency	+10 ms monthly p99	At most 100 keys per request and at most 128 KiB of request and response metadata. Every key retains its individual success or error result.	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.
S3	S3 to MinIO Storage	Multipart setup, parts and completion adapter-added latency	+5 ms monthly p99	At most 100 parts at completion; a part request is at most 64 KiB for this latency class. The target’s supported multipart limits still apply. Larger parts are covered by a separately agreed streaming budget.	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.
S3	S3 to MinIO Storage	Bucket configuration requests adapter-added latency	+20 ms monthly p99	One bucket; at most 32 KiB configuration and 50 policy or rule entries. Measures the API response, not asynchronous replication, lifecycle transitions or data migration.	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.
S3	S3 to MinIO Storage	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful write must preserve the accepted bytes and supported metadata; a failed replacement must not be reported as successful. Version IDs, delete markers, conditional requests, ACLs and retention follow this directed profile, not an assumed universal S3 contract. Target storage durability remains the provider’s responsibility; Tensor9 is responsible for corrupting, misrouting or prematurely acknowledging a request in its own code.
S3	S3 to MinIO Storage	Endpoint reachability	99.9% per calendar month	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.
S3	S3 to MinIO Storage	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
S3	S3 to OCI Object Storage	Small object and metadata requests adapter-added latency	+1 ms monthly p99	One object; complete request and response bodies each at most 64 KiB, metadata at most 8 KiB. No archive restore or multipart completion. Larger streaming bodies need a byte-rate and completion budget in the agreement.	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.
S3	S3 to OCI Object Storage	Bounded object copy adapter-added latency	+3 ms monthly p99	One source and destination, object at most 64 KiB, metadata at most 8 KiB. Only supported source conditions and ranges are covered.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
S3	S3 to OCI Object Storage	Bounded object and multipart listing adapter-added latency	+3 ms monthly p99	One page with at most 1,000 returned entries and 1 MiB of encoded response. No implicit traversal of later pages.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
S3	S3 to OCI Object Storage	Bounded multi-object deletion adapter-added latency	+10 ms monthly p99	At most 100 keys per request and at most 128 KiB of request and response metadata. Every key retains its individual success or error result.	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.
S3	S3 to OCI Object Storage	Multipart setup, parts and completion adapter-added latency	+5 ms monthly p99	At most 100 parts at completion; a part request is at most 64 KiB for this latency class. The target’s supported multipart limits still apply. Larger parts are covered by a separately agreed streaming budget.	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.
S3	S3 to OCI Object Storage	Bucket configuration requests adapter-added latency	+20 ms monthly p99	One bucket; at most 32 KiB configuration and 50 policy or rule entries. Measures the API response, not asynchronous replication, lifecycle transitions or data migration.	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.
S3	S3 to OCI Object Storage	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful write must preserve the accepted bytes and supported metadata; a failed replacement must not be reported as successful. Version IDs, delete markers, conditional requests, ACLs and retention follow this directed profile, not an assumed universal S3 contract. Target storage durability remains the provider’s responsibility; Tensor9 is responsible for corrupting, misrouting or prematurely acknowledging a request in its own code.
S3	S3 to OCI Object Storage	Endpoint reachability	99.9% per calendar month	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.
S3	S3 to OCI Object Storage	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
S3	S3 to Scaleway Object Storage	Small object and metadata requests adapter-added latency	+1 ms monthly p99	One object; complete request and response bodies each at most 64 KiB, metadata at most 8 KiB. No archive restore or multipart completion. Larger streaming bodies need a byte-rate and completion budget in the agreement.	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.
S3	S3 to Scaleway Object Storage	Bounded object copy adapter-added latency	+3 ms monthly p99	One source and destination, object at most 64 KiB, metadata at most 8 KiB. Only supported source conditions and ranges are covered.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
S3	S3 to Scaleway Object Storage	Bounded object and multipart listing adapter-added latency	+3 ms monthly p99	One page with at most 1,000 returned entries and 1 MiB of encoded response. No implicit traversal of later pages.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
S3	S3 to Scaleway Object Storage	Bounded multi-object deletion adapter-added latency	+10 ms monthly p99	At most 100 keys per request and at most 128 KiB of request and response metadata. Every key retains its individual success or error result.	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.
S3	S3 to Scaleway Object Storage	Multipart setup, parts and completion adapter-added latency	+5 ms monthly p99	At most 100 parts at completion; a part request is at most 64 KiB for this latency class. The target’s supported multipart limits still apply. Larger parts are covered by a separately agreed streaming budget.	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.
S3	S3 to Scaleway Object Storage	Bucket configuration requests adapter-added latency	+20 ms monthly p99	One bucket; at most 32 KiB configuration and 50 policy or rule entries. Measures the API response, not asynchronous replication, lifecycle transitions or data migration.	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.
S3	S3 to Scaleway Object Storage	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A successful write must preserve the accepted bytes and supported metadata; a failed replacement must not be reported as successful. Version IDs, delete markers, conditional requests, ACLs and retention follow this directed profile, not an assumed universal S3 contract. Target storage durability remains the provider’s responsibility; Tensor9 is responsible for corrupting, misrouting or prematurely acknowledging a request in its own code.
S3	S3 to Scaleway Object Storage	Endpoint reachability	99.9% per calendar month	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.
S3	S3 to Scaleway Object Storage	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SNS	SNS (Simple Notification Service) to Google Cloud Pub/Sub	Bounded notification acceptance adapter-added latency	+3 ms monthly p99	One message at most 4 KiB, at most 20 subscriptions and 20 bounded filter clauses. Measures Publish acceptance, not downstream subscriber completion.	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.
SNS	SNS (Simple Notification Service) to Google Cloud Pub/Sub	Bounded notification batch acceptance adapter-added latency	+10 ms monthly p99	At most 10 messages, 40 KiB aggregate bytes and 20 subscriptions per topic; per-entry results retained.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SNS	SNS (Simple Notification Service) to Google Cloud Pub/Sub	Topic and subscription configuration adapter-added latency	+20 ms monthly p99	One topic or subscription, at most 50 tags and 32 KiB settings. Subscribe and ConfirmSubscription retain their receiver-consent and protocol restrictions.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SNS	SNS (Simple Notification Service) to Google Cloud Pub/Sub	Bounded topic and subscription pages adapter-added latency	+20 ms monthly p99	One page with at most 100 entries and 128 KiB encoded response; no traversal of subsequent pages.	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.
SNS	SNS (Simple Notification Service) to Google Cloud Pub/Sub	Documented adapter behavior	Preserve the supported behavior documented for this adapter	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.
SNS	SNS (Simple Notification Service) to Google Cloud Pub/Sub	Endpoint reachability	99.9% per calendar month	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.
SNS	SNS (Simple Notification Service) to Google Cloud Pub/Sub	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SNS	SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL	Bounded notification acceptance adapter-added latency	+20 ms monthly p99	One message at most 4 KiB, at most 20 subscriptions and 20 bounded filter clauses. Measures Publish acceptance, not downstream subscriber completion.	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.
SNS	SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL	Bounded notification batch acceptance adapter-added latency	+50 ms monthly p99	At most 10 messages, 40 KiB aggregate bytes and 20 subscriptions per topic; per-entry results retained.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SNS	SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL	Topic and subscription configuration adapter-added latency	+20 ms monthly p99	One topic or subscription, at most 50 tags and 32 KiB settings. Subscribe and ConfirmSubscription retain their receiver-consent and protocol restrictions.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SNS	SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL	Bounded topic and subscription pages adapter-added latency	+20 ms monthly p99	One page with at most 100 entries and 128 KiB encoded response; no traversal of subsequent pages.	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.
SNS	SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	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.
SNS	SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
SNS	SNS (Simple Notification Service) to Google Cloud SQL for PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SNS	SNS (Simple Notification Service) to PostgreSQL	Bounded notification acceptance adapter-added latency	+20 ms monthly p99	One message at most 4 KiB, at most 20 subscriptions and 20 bounded filter clauses. Measures Publish acceptance, not downstream subscriber completion.	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.
SNS	SNS (Simple Notification Service) to PostgreSQL	Bounded notification batch acceptance adapter-added latency	+50 ms monthly p99	At most 10 messages, 40 KiB aggregate bytes and 20 subscriptions per topic; per-entry results retained.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SNS	SNS (Simple Notification Service) to PostgreSQL	Topic and subscription configuration adapter-added latency	+20 ms monthly p99	One topic or subscription, at most 50 tags and 32 KiB settings. Subscribe and ConfirmSubscription retain their receiver-consent and protocol restrictions.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SNS	SNS (Simple Notification Service) to PostgreSQL	Bounded topic and subscription pages adapter-added latency	+20 ms monthly p99	One page with at most 100 entries and 128 KiB encoded response; no traversal of subsequent pages.	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.
SNS	SNS (Simple Notification Service) to PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	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.
SNS	SNS (Simple Notification Service) to PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
SNS	SNS (Simple Notification Service) to PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Azure Service Bus	Small message send and settlement adapter-added latency	+1 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Azure Service Bus	Bounded short-poll receive adapter-added latency	+3 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Azure Service Bus	Bounded message batches adapter-added latency	+10 ms monthly p99	At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Azure Service Bus	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Azure Service Bus	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Azure Service Bus	Endpoint reachability	99.9% per calendar month	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Azure Service Bus	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Cloud SQL for PostgreSQL	Not applicable	No numerical term	FIFO request-processing service levels have not been qualified for this mapping. Standard-queue measurements do not establish FIFO latency, throughput or availability.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to PostgreSQL	Not applicable	No numerical term	FIFO request-processing service levels have not been qualified for this mapping. Standard-queue measurements do not establish FIFO latency, throughput or availability.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server	Small message send and settlement adapter-added latency	+10 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server	Bounded short-poll receive adapter-added latency	+10 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server	Bounded message batches adapter-added latency	+100 ms monthly p99	At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server	Endpoint reachability	99.9% per calendar month	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to PostgreSQL Flexible Server	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL	Small message send and settlement adapter-added latency	+10 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL	Bounded short-poll receive adapter-added latency	+10 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL	Bounded message batches adapter-added latency	+100 ms monthly p99	At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
SQS (FIFO)	SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database for PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Queue Storage	Small message send and settlement adapter-added latency	+1 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Queue Storage	Bounded short-poll receive adapter-added latency	+3 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Queue Storage	Bounded message batches adapter-added latency	+10 ms monthly p99	At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Queue Storage	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Queue Storage	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Queue Storage	Endpoint reachability	99.9% per calendar month	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Queue Storage	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Service Bus	Small message send and settlement adapter-added latency	+1 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Service Bus	Bounded short-poll receive adapter-added latency	+3 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Service Bus	Bounded message batches adapter-added latency	+10 ms monthly p99	At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Service Bus	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Service Bus	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Service Bus	Endpoint reachability	99.9% per calendar month	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Azure Service Bus	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to OCI Queue	Small message send and settlement adapter-added latency	+1 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to OCI Queue	Bounded short-poll receive adapter-added latency	+3 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to OCI Queue	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to OCI Queue	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to OCI Queue	Endpoint reachability	99.9% per calendar month	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to OCI Queue	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL	Small message send and settlement adapter-added latency	+3 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL	Bounded short-poll receive adapter-added latency	+10 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL	Bounded message batches adapter-added latency	+30 ms monthly p99	At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL Flexible Server	Small message send and settlement adapter-added latency	+3 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL Flexible Server	Bounded short-poll receive adapter-added latency	+10 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL Flexible Server	Bounded message batches adapter-added latency	+30 ms monthly p99	At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL Flexible Server	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL Flexible Server	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL Flexible Server	Endpoint reachability	99.9% per calendar month	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to PostgreSQL Flexible Server	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Pub/Sub	Small message send and settlement adapter-added latency	+1 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Pub/Sub	Bounded short-poll receive adapter-added latency	+3 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Pub/Sub	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Pub/Sub	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Pub/Sub	Endpoint reachability	99.9% per calendar month	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Pub/Sub	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Managed Database for PostgreSQL	Small message send and settlement adapter-added latency	+3 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Managed Database for PostgreSQL	Bounded short-poll receive adapter-added latency	+10 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Managed Database for PostgreSQL	Bounded message batches adapter-added latency	+30 ms monthly p99	At most 10 entries and 40 KiB aggregate data. Same point-operation limits, applied to each entry; every entry gets its own success/error result.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Managed Database for PostgreSQL	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Managed Database for PostgreSQL	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Managed Database for PostgreSQL	Endpoint reachability	99.9% per calendar month	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Managed Database for PostgreSQL	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Queues (SQS-compatible)	Small message send and settlement adapter-added latency	+1 ms monthly p99	One message at most 4 KiB including attributes; one group for FIFO; no redrive transition or contention retry. Adapter metadata/coordination waits remain included. Higher contention needs an agreed separate class.	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Queues (SQS-compatible)	Bounded short-poll receive adapter-added latency	+3 ms monthly p99	WaitTimeSeconds=0; at most 10 messages, 40 KiB aggregate bodies/attributes, at most 100 inspected candidates or active groups, no dead-letter transfer. Long-poll timeout and message-arrival latency are separate, not silently subtracted from this row.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Queues (SQS-compatible)	Queue configuration and discovery adapter-added latency	+20 ms monthly p99	One queue, at most 50 tags and 32 KiB configuration, or a page of at most 100 queues. Purge measures request acceptance, not complete physical reclamation or receipt invalidation across every worker.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Queues (SQS-compatible)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Acceptance must not be returned before the documented message persistence point. Settlement must apply to the intended message/receipt; FIFO order and deduplication apply only where this directed profile supports them. Duplicate delivery can be legitimate under at-least-once delivery. Dead-letter transitions must not silently discard an accepted message. Durability of the target broker/database remains its own commitment, while broken adapter receipt, marker or coordination logic remains Tensor9’s responsibility.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Queues (SQS-compatible)	Endpoint reachability	99.9% per calendar month	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.
SQS (Simple Queue Service, Classic)	SQS (Simple Queue Service, Classic) to Scaleway Queues (SQS-compatible)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
SQS (Simple Queue Service, Classic)	SQS to Cloud SQL for PostgreSQL	Endpoint reachability	99.9% per calendar month	Tests whether the endpoint can be reached, separately from whether requests complete correctly. Measure each queue type separately.	What Tensor9 covers. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results.
SQS (Simple Queue Service, Classic)	SQS to Cloud SQL for PostgreSQL	SendMessage, DeleteMessage, ChangeMessageVisibility adapter-added latency	+10 ms monthly p99	Message body ≤1 KiB and attributes ≤1 KiB. Use supported request options.	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. How queue timing works. Time spent waiting for a message in an empty queue does not count as adapter delay. Adapter delays after a message becomes available, or after the requested wait ends, do count. The message-pickup target is not a deadline for clearing a backlog. Measure Standard and FIFO queues separately, and check each batch entry’s result. Empty receives and internal retries do not count as successfully delivered messages.
SQS (Simple Queue Service, Classic)	SQS to Cloud SQL for PostgreSQL	SendMessageBatch, DeleteMessageBatch adapter-added latency	+100 ms monthly p99	≤10 entries, each within the body, attribute and API limits.	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. Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA.
SQS (Simple Queue Service, Classic)	SQS to Cloud SQL for PostgreSQL	ReceiveMessage: ready-message pickup adapter-added latency	+250 ms monthly p99	One available message and one waiting request for a single message; body/attributes ≤1 KiB. No competing backlog, receiver, or earlier FIFO message blocking delivery.	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. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.
SQS (Simple Queue Service, Classic)	SQS to Cloud SQL for PostgreSQL	ReceiveMessage: delay after the requested wait adapter-added latency	+250 ms monthly p99	Count adapter delay after the requested waiting period ends, not the time spent waiting for a message.	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.
SQS (Simple Queue Service, Classic)	SQS to Cloud SQL for PostgreSQL	Saving messages and completed processing	Save the required data durably before returning success	Preserve confirmed sends, message visibility, expiration, completed processing and dead-letter handling after a failure. This is not a guarantee of the provider’s storage-durability percentage.
SQS (Simple Queue Service, Classic)	SQS to Cloud SQL for PostgreSQL	Delivery, ordering and deduplication	Delivery behavior as documented for this adapter	Standard queues may deliver a message again. FIFO preserves the documented order and duplicate handling within each message group. Your application must still handle retries without repeating business actions.
SQS (Simple Queue Service, Classic)	SQS to Cloud SQL for PostgreSQL	Adapter autoscaling and limits	Automatic scaling within agreed traffic and deployment limits	Set separate limits for Standard and FIFO queues. Include completed send/receive/delete cycles, message sizes and attributes, total connections, message claims and locks, FIFO groups, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Backend capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits.
SQS (Simple Queue Service, Classic) / SQS (FIFO)	SQS to Cosmos DB (SQS (Simple Queue Service, Classic)) SQS to Cosmos DB (SQS (FIFO))	Endpoint reachability	99.9% per calendar month	Tests whether the endpoint can be reached, separately from whether requests complete correctly. Measure each queue type separately.	What Tensor9 covers. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results.
SQS (Simple Queue Service, Classic) / SQS (FIFO)	SQS to Cosmos DB (SQS (Simple Queue Service, Classic)) SQS to Cosmos DB (SQS (FIFO))	SendMessage, DeleteMessage, ChangeMessageVisibility adapter-added latency	+20 ms monthly p99	Message body ≤1 KiB and attributes ≤1 KiB. Use supported request options.	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. How queue timing works. Time spent waiting for a message in an empty queue does not count as adapter delay. Adapter delays after a message becomes available, or after the requested wait ends, do count. The message-pickup target is not a deadline for clearing a backlog. Measure Standard and FIFO queues separately, and check each batch entry’s result. Empty receives and internal retries do not count as successfully delivered messages.
SQS (Simple Queue Service, Classic) / SQS (FIFO)	SQS to Cosmos DB (SQS (Simple Queue Service, Classic)) SQS to Cosmos DB (SQS (FIFO))	SendMessageBatch adapter-added latency	+200 ms monthly p99	≤10 entries, each within the body, attribute and API limits. `DeleteMessageBatch` is not covered.	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. Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA.
SQS (Simple Queue Service, Classic) / SQS (FIFO)	SQS to Cosmos DB (SQS (Simple Queue Service, Classic)) SQS to Cosmos DB (SQS (FIFO))	ReceiveMessage: ready-message pickup adapter-added latency	+500 ms monthly p99	One available message and one waiting request for a single message; body/attributes ≤1 KiB. No competing backlog, receiver, or earlier FIFO message blocking delivery.	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. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.
SQS (Simple Queue Service, Classic) / SQS (FIFO)	SQS to Cosmos DB (SQS (Simple Queue Service, Classic)) SQS to Cosmos DB (SQS (FIFO))	ReceiveMessage: delay after the requested wait adapter-added latency	+500 ms monthly p99	Count adapter delay after the requested waiting period ends, not the time spent waiting for a message.	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.
SQS (Simple Queue Service, Classic) / SQS (FIFO)	SQS to Cosmos DB (SQS (Simple Queue Service, Classic)) SQS to Cosmos DB (SQS (FIFO))	Saving messages and completed processing	Save the required data durably before returning success	Safely assign messages to receivers and preserve visibility, expiration, completed processing and dead-letter handling after a failure. The adapter must not lose accepted messages.
SQS (Simple Queue Service, Classic) / SQS (FIFO)	SQS to Cosmos DB (SQS (Simple Queue Service, Classic)) SQS to Cosmos DB (SQS (FIFO))	Delivery, ordering and deduplication	Delivery behavior as documented for this adapter	Standard queues may deliver a message again. FIFO preserves the documented order and duplicate handling within each message group. Your application must still handle retries without repeating business actions.
SQS (Simple Queue Service, Classic) / SQS (FIFO)	SQS to Cosmos DB (SQS (Simple Queue Service, Classic)) SQS to Cosmos DB (SQS (FIFO))	Adapter autoscaling and limits	Automatic scaling within agreed traffic and deployment limits	Set separate limits for Standard and FIFO queues. Include completed send/receive/delete cycles, message sizes and attributes, partitions, conditional message claims, FIFO groups, traffic growth and bursts, and spare capacity for failures. The standard service level promises no fixed request rate, reserved throughput or unlimited scaling. Backend capacity is separate. Adapter scaling delays still count toward the SLA while traffic stays within the agreed limits.
Secrets Manager	Secrets Manager to Key Vault	Secret point reads adapter-added latency	+4 ms monthly p99	Secret value at most 64 KiB; one secret/version; policy at most 32 KiB.	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.
Secrets Manager	Secrets Manager to Key Vault	Bounded secret lists adapter-added latency	+12 ms monthly p99	at most 20 secrets or at most 100 metadata entries; at most 1 MiB returned secret data.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Secrets Manager	Secrets Manager to Key Vault	Secret and policy mutation adapter-added latency	+12 ms monthly p99	One secret; value at most 64 KiB; at most 20 stages and tags.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Secrets Manager	Secrets Manager to Key Vault	Rotation and replication coordination adapter-added latency	+25 ms monthly p99	One secret and at most 5 replicas; callback/provider execution excluded by spans.	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.
Secrets Manager	Secrets Manager to Key Vault	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A returned success means secret material and version metadata are durable. AWSCURRENT/AWSPREVIOUS transitions remain atomic, recovery windows are honored, resource policies never widen on translation, and replica or rotation failures cannot expose an uncommitted version.
Secrets Manager	Secrets Manager to Key Vault	Endpoint reachability	99.9% per calendar month	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.
Secrets Manager	Secrets Manager to Key Vault	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Secrets Manager	Secrets Manager to Kubernetes Secret	Secret point reads adapter-added latency	+4 ms monthly p99	Secret value at most 64 KiB; one secret/version; policy at most 32 KiB.	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.
Secrets Manager	Secrets Manager to Kubernetes Secret	Bounded secret lists adapter-added latency	+12 ms monthly p99	at most 20 secrets or at most 100 metadata entries; at most 1 MiB returned secret data.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Secrets Manager	Secrets Manager to Kubernetes Secret	Secret and policy mutation adapter-added latency	+12 ms monthly p99	One secret; value at most 64 KiB; at most 20 stages and tags.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Secrets Manager	Secrets Manager to Kubernetes Secret	Rotation and replication coordination adapter-added latency	+25 ms monthly p99	One secret and at most 5 replicas; callback/provider execution excluded by spans.	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.
Secrets Manager	Secrets Manager to Kubernetes Secret	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A returned success means secret material and version metadata are durable. AWSCURRENT/AWSPREVIOUS transitions remain atomic, recovery windows are honored, resource policies never widen on translation, and replica or rotation failures cannot expose an uncommitted version.
Secrets Manager	Secrets Manager to Kubernetes Secret	Endpoint reachability	99.9% per calendar month	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.
Secrets Manager	Secrets Manager to Kubernetes Secret	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Secrets Manager	Secrets Manager to OCI Vault	Secret point reads adapter-added latency	+4 ms monthly p99	Secret value at most 64 KiB; one secret/version; policy at most 32 KiB.	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.
Secrets Manager	Secrets Manager to OCI Vault	Bounded secret lists adapter-added latency	+12 ms monthly p99	at most 20 secrets or at most 100 metadata entries; at most 1 MiB returned secret data.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Secrets Manager	Secrets Manager to OCI Vault	Secret and policy mutation adapter-added latency	+12 ms monthly p99	One secret; value at most 64 KiB; at most 20 stages and tags.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Secrets Manager	Secrets Manager to OCI Vault	Rotation and replication coordination adapter-added latency	+25 ms monthly p99	One secret and at most 5 replicas; callback/provider execution excluded by spans.	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.
Secrets Manager	Secrets Manager to OCI Vault	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A returned success means secret material and version metadata are durable. AWSCURRENT/AWSPREVIOUS transitions remain atomic, recovery windows are honored, resource policies never widen on translation, and replica or rotation failures cannot expose an uncommitted version.
Secrets Manager	Secrets Manager to OCI Vault	Endpoint reachability	99.9% per calendar month	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.
Secrets Manager	Secrets Manager to OCI Vault	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Secrets Manager	Secrets Manager to Secret Manager	Secret point reads adapter-added latency	+4 ms monthly p99	Secret value at most 64 KiB; one secret/version; policy at most 32 KiB.	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.
Secrets Manager	Secrets Manager to Secret Manager	Bounded secret lists adapter-added latency	+12 ms monthly p99	at most 20 secrets or at most 100 metadata entries; at most 1 MiB returned secret data.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Secrets Manager	Secrets Manager to Secret Manager	Secret and policy mutation adapter-added latency	+12 ms monthly p99	One secret; value at most 64 KiB; at most 20 stages and tags.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Secrets Manager	Secrets Manager to Secret Manager	Rotation and replication coordination adapter-added latency	+25 ms monthly p99	One secret and at most 5 replicas; callback/provider execution excluded by spans.	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.
Secrets Manager	Secrets Manager to Secret Manager	Documented adapter behavior	Preserve the supported behavior documented for this adapter	A returned success means secret material and version metadata are durable. AWSCURRENT/AWSPREVIOUS transitions remain atomic, recovery windows are honored, resource policies never widen on translation, and replica or rotation failures cannot expose an uncommitted version.
Secrets Manager	Secrets Manager to Secret Manager	Endpoint reachability	99.9% per calendar month	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.
Secrets Manager	Secrets Manager to Secret Manager	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Step Functions	Step Functions to Azure Durable Functions	Workflow and execution reads adapter-added latency	+8 ms monthly p99	at most 100 returned records/history events and at most 1 MiB payload.	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.
Step Functions	Step Functions to Azure Durable Functions	Definition, version, alias and tag mutation adapter-added latency	+15 ms monthly p99	Definition at most 1 MiB and at most 100 states; one named resource.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Step Functions	Step Functions to Azure Durable Functions	Execution and task coordination adapter-added latency	+12 ms monthly p99	Payload at most 256 KiB; one execution/task token; customer task execution excluded.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Step Functions	Step Functions to Azure Durable Functions	Activity poll processing adapter-added latency	+5 ms monthly p99	Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately.	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.
Step Functions	Step Functions to Azure Durable Functions	Bounded synchronous workflow processing adapter-added latency	+25 ms monthly p99	Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans.	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.
Step Functions	Step Functions to Azure Durable Functions	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
Step Functions	Step Functions to Azure Durable Functions	Endpoint reachability	99.9% per calendar month	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.
Step Functions	Step Functions to Azure Durable Functions	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Step Functions	Step Functions to Cloud Workflows	Workflow and execution reads adapter-added latency	+8 ms monthly p99	at most 100 returned records/history events and at most 1 MiB payload.	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.
Step Functions	Step Functions to Cloud Workflows	Definition, version, alias and tag mutation adapter-added latency	+15 ms monthly p99	Definition at most 1 MiB and at most 100 states; one named resource.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Step Functions	Step Functions to Cloud Workflows	Execution and task coordination adapter-added latency	+12 ms monthly p99	Payload at most 256 KiB; one execution/task token; customer task execution excluded.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Step Functions	Step Functions to Cloud Workflows	Activity poll processing adapter-added latency	+5 ms monthly p99	Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately.	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.
Step Functions	Step Functions to Cloud Workflows	Bounded synchronous workflow processing adapter-added latency	+25 ms monthly p99	Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans.	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.
Step Functions	Step Functions to Cloud Workflows	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
Step Functions	Step Functions to Cloud Workflows	Endpoint reachability	99.9% per calendar month	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.
Step Functions	Step Functions to Cloud Workflows	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Step Functions	Step Functions to Temporal (Self-Hosted)	Workflow and execution reads adapter-added latency	+8 ms monthly p99	at most 100 returned records/history events and at most 1 MiB payload.	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.
Step Functions	Step Functions to Temporal (Self-Hosted)	Definition, version, alias and tag mutation adapter-added latency	+15 ms monthly p99	Definition at most 1 MiB and at most 100 states; one named resource.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Step Functions	Step Functions to Temporal (Self-Hosted)	Execution and task coordination adapter-added latency	+12 ms monthly p99	Payload at most 256 KiB; one execution/task token; customer task execution excluded.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Step Functions	Step Functions to Temporal (Self-Hosted)	Activity poll processing adapter-added latency	+5 ms monthly p99	Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately.	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.
Step Functions	Step Functions to Temporal (Self-Hosted)	Bounded synchronous workflow processing adapter-added latency	+25 ms monthly p99	Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans.	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.
Step Functions	Step Functions to Temporal (Self-Hosted)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
Step Functions	Step Functions to Temporal (Self-Hosted)	Endpoint reachability	99.9% per calendar month	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.
Step Functions	Step Functions to Temporal (Self-Hosted)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Step Functions	Step Functions to Temporal Cloud (Managed)	Workflow and execution reads adapter-added latency	+8 ms monthly p99	at most 100 returned records/history events and at most 1 MiB payload.	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.
Step Functions	Step Functions to Temporal Cloud (Managed)	Definition, version, alias and tag mutation adapter-added latency	+15 ms monthly p99	Definition at most 1 MiB and at most 100 states; one named resource.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Step Functions	Step Functions to Temporal Cloud (Managed)	Execution and task coordination adapter-added latency	+12 ms monthly p99	Payload at most 256 KiB; one execution/task token; customer task execution excluded.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Step Functions	Step Functions to Temporal Cloud (Managed)	Activity poll processing adapter-added latency	+5 ms monthly p99	Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately.	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.
Step Functions	Step Functions to Temporal Cloud (Managed)	Bounded synchronous workflow processing adapter-added latency	+25 ms monthly p99	Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans.	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.
Step Functions	Step Functions to Temporal Cloud (Managed)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
Step Functions	Step Functions to Temporal Cloud (Managed)	Endpoint reachability	99.9% per calendar month	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.
Step Functions	Step Functions to Temporal Cloud (Managed)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Step Functions State Machine	Step Functions State Machine to Azure Durable Functions	Workflow and execution reads adapter-added latency	+8 ms monthly p99	at most 100 returned records/history events and at most 1 MiB payload.	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.
Step Functions State Machine	Step Functions State Machine to Azure Durable Functions	Definition, version, alias and tag mutation adapter-added latency	+15 ms monthly p99	Definition at most 1 MiB and at most 100 states; one named resource.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Step Functions State Machine	Step Functions State Machine to Azure Durable Functions	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Step Functions State Machine	Step Functions State Machine to Azure Durable Functions	Endpoint reachability	99.9% per calendar month	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.
Step Functions State Machine	Step Functions State Machine to Azure Durable Functions	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Step Functions State Machine	Step Functions State Machine to Cloud Workflows	Workflow and execution reads adapter-added latency	+8 ms monthly p99	at most 100 returned records/history events and at most 1 MiB payload.	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.
Step Functions State Machine	Step Functions State Machine to Cloud Workflows	Definition, version, alias and tag mutation adapter-added latency	+15 ms monthly p99	Definition at most 1 MiB and at most 100 states; one named resource.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Step Functions State Machine	Step Functions State Machine to Cloud Workflows	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Step Functions State Machine	Step Functions State Machine to Cloud Workflows	Endpoint reachability	99.9% per calendar month	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.
Step Functions State Machine	Step Functions State Machine to Cloud Workflows	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Step Functions State Machine	Step Functions State Machine to Temporal (Self-Hosted)	Workflow and execution reads adapter-added latency	+8 ms monthly p99	at most 100 returned records/history events and at most 1 MiB payload.	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.
Step Functions State Machine	Step Functions State Machine to Temporal (Self-Hosted)	Definition, version, alias and tag mutation adapter-added latency	+15 ms monthly p99	Definition at most 1 MiB and at most 100 states; one named resource.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Step Functions State Machine	Step Functions State Machine to Temporal (Self-Hosted)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Step Functions State Machine	Step Functions State Machine to Temporal (Self-Hosted)	Endpoint reachability	99.9% per calendar month	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.
Step Functions State Machine	Step Functions State Machine to Temporal (Self-Hosted)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Step Functions State Machine	Step Functions State Machine to Temporal Cloud (Managed)	Workflow and execution reads adapter-added latency	+8 ms monthly p99	at most 100 returned records/history events and at most 1 MiB payload.	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.
Step Functions State Machine	Step Functions State Machine to Temporal Cloud (Managed)	Definition, version, alias and tag mutation adapter-added latency	+15 ms monthly p99	Definition at most 1 MiB and at most 100 states; one named resource.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Step Functions State Machine	Step Functions State Machine to Temporal Cloud (Managed)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Step Functions State Machine	Step Functions State Machine to Temporal Cloud (Managed)	Endpoint reachability	99.9% per calendar month	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.
Step Functions State Machine	Step Functions State Machine to Temporal Cloud (Managed)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Systems Manager (SSM)	Systems Manager (SSM) to Azure App Configuration	Point parameter reads adapter-added latency	+3 ms monthly p99	Value at most 64 KiB; one named parameter and version. GetParameterHistory requires exactly one retained version, not a one-entry page from a longer history.	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.
Systems Manager (SSM)	Systems Manager (SSM) to Azure App Configuration	Bounded batch and path reads adapter-added latency	+10 ms monthly p99	at most 50 requested or returned parameters and at most 1 MiB total values.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Systems Manager (SSM)	Systems Manager (SSM) to Azure App Configuration	Parameter and version mutation adapter-added latency	+10 ms monthly p99	One parameter, at most 64 KiB value, at most 100 retained versions/labels. DeleteParameters covers a one-name batch; larger batches require a separately agreed budget.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Systems Manager (SSM)	Systems Manager (SSM) to Azure App Configuration	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access.
Systems Manager (SSM)	Systems Manager (SSM) to Azure App Configuration	Endpoint reachability	99.9% per calendar month	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.
Systems Manager (SSM)	Systems Manager (SSM) to Azure App Configuration	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Systems Manager (SSM)	Systems Manager (SSM) to Google Parameter Manager	Point parameter reads adapter-added latency	+3 ms monthly p99	Value at most 64 KiB; one named parameter and version. GetParameterHistory requires exactly one retained version, not a one-entry page from a longer history.	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.
Systems Manager (SSM)	Systems Manager (SSM) to Google Parameter Manager	Bounded batch and path reads adapter-added latency	+10 ms monthly p99	at most 50 requested or returned parameters and at most 1 MiB total values.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Systems Manager (SSM)	Systems Manager (SSM) to Google Parameter Manager	Parameter and version mutation adapter-added latency	+10 ms monthly p99	One parameter, at most 64 KiB value, at most 100 retained versions/labels. DeleteParameters covers a one-name batch; larger batches require a separately agreed budget.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Systems Manager (SSM)	Systems Manager (SSM) to Google Parameter Manager	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access.
Systems Manager (SSM)	Systems Manager (SSM) to Google Parameter Manager	Endpoint reachability	99.9% per calendar month	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.
Systems Manager (SSM)	Systems Manager (SSM) to Google Parameter Manager	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Systems Manager (SSM)	Systems Manager (SSM) to Kubernetes Secrets	Point parameter reads adapter-added latency	+3 ms monthly p99	Value at most 64 KiB; one named parameter and version. GetParameterHistory requires exactly one retained version, not a one-entry page from a longer history.	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.
Systems Manager (SSM)	Systems Manager (SSM) to Kubernetes Secrets	Bounded batch and path reads adapter-added latency	+10 ms monthly p99	at most 50 requested or returned parameters and at most 1 MiB total values.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Systems Manager (SSM)	Systems Manager (SSM) to Kubernetes Secrets	Parameter and version mutation adapter-added latency	+10 ms monthly p99	One parameter, at most 64 KiB value, at most 100 retained versions/labels. DeleteParameters covers a one-name batch; larger batches require a separately agreed budget.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Systems Manager (SSM)	Systems Manager (SSM) to Kubernetes Secrets	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access.
Systems Manager (SSM)	Systems Manager (SSM) to Kubernetes Secrets	Endpoint reachability	99.9% per calendar month	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.
Systems Manager (SSM)	Systems Manager (SSM) to Kubernetes Secrets	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Systems Manager (SSM)	Systems Manager (SSM) to OCI Vault	Point parameter reads adapter-added latency	+3 ms monthly p99	Value at most 64 KiB; one named parameter and version. GetParameterHistory requires exactly one retained version, not a one-entry page from a longer history.	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.
Systems Manager (SSM)	Systems Manager (SSM) to OCI Vault	Bounded batch and path reads adapter-added latency	+10 ms monthly p99	at most 50 requested or returned parameters and at most 1 MiB total values.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Systems Manager (SSM)	Systems Manager (SSM) to OCI Vault	Parameter and version mutation adapter-added latency	+10 ms monthly p99	One parameter, at most 64 KiB value, at most 100 retained versions/labels. DeleteParameters covers a one-name batch; larger batches require a separately agreed budget.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Systems Manager (SSM)	Systems Manager (SSM) to OCI Vault	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access.
Systems Manager (SSM)	Systems Manager (SSM) to OCI Vault	Endpoint reachability	99.9% per calendar month	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.
Systems Manager (SSM)	Systems Manager (SSM) to OCI Vault	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
Systems Manager (SSM)	Systems Manager (SSM) to Secret Manager	Point parameter reads adapter-added latency	+3 ms monthly p99	Value at most 64 KiB; one named parameter and version. GetParameterHistory requires exactly one retained version, not a one-entry page from a longer history.	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.
Systems Manager (SSM)	Systems Manager (SSM) to Secret Manager	Bounded batch and path reads adapter-added latency	+10 ms monthly p99	at most 50 requested or returned parameters and at most 1 MiB total values.	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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Systems Manager (SSM)	Systems Manager (SSM) to Secret Manager	Parameter and version mutation adapter-added latency	+10 ms monthly p99	One parameter, at most 64 KiB value, at most 100 retained versions/labels. DeleteParameters covers a one-name batch; larger batches require a separately agreed budget.	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. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
Systems Manager (SSM)	Systems Manager (SSM) to Secret Manager	Documented adapter behavior	Preserve the supported behavior documented for this adapter	Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access.
Systems Manager (SSM)	Systems Manager (SSM) to Secret Manager	Endpoint reachability	99.9% per calendar month	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.
Systems Manager (SSM)	Systems Manager (SSM) to Secret Manager	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
VPC	VPC to Scaleway VPC	Not applicable	No numerical term	This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider’s networking terms apply.
VPC	VPC to Tensor9 Trivial	Not applicable	No numerical term	This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider’s networking terms apply.
VPC	VPC to Virtual Cloud Network	Bounded VPC management reads adapter-added latency	+10 ms monthly p99	One point read or at most 100 returned network objects and at most 20 filters.	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.
VPC	VPC to Virtual Cloud Network	VPC topology and policy mutation adapter-added latency	+25 ms monthly p99	One object or at most 100 security, route, ACL, address, interface or tag entries; target readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
VPC	VPC to Virtual Cloud Network	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
VPC	VPC to Virtual Cloud Network	Endpoint reachability	99.9% per calendar month	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.
VPC	VPC to Virtual Cloud Network	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
VPC	VPC to Virtual Network	Bounded VPC management reads adapter-added latency	+10 ms monthly p99	One point read or at most 100 returned network objects and at most 20 filters.	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.
VPC	VPC to Virtual Network	VPC topology and policy mutation adapter-added latency	+25 ms monthly p99	One object or at most 100 security, route, ACL, address, interface or tag entries; target readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
VPC	VPC to Virtual Network	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
VPC	VPC to Virtual Network	Endpoint reachability	99.9% per calendar month	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.
VPC	VPC to Virtual Network	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.
VPC	VPC to Virtual Private Cloud (VPC)	Bounded VPC management reads adapter-added latency	+10 ms monthly p99	One point read or at most 100 returned network objects and at most 20 filters.	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.
VPC	VPC to Virtual Private Cloud (VPC)	VPC topology and policy mutation adapter-added latency	+25 ms monthly p99	One object or at most 100 security, route, ACL, address, interface or tag entries; target readiness 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. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
VPC	VPC to Virtual Private Cloud (VPC)	Documented adapter behavior	Preserve the supported behavior documented for this adapter	The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.	Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
VPC	VPC to Virtual Private Cloud (VPC)	Endpoint reachability	99.9% per calendar month	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.
VPC	VPC to Virtual Private Cloud (VPC)	Adapter autoscaling and limits	Automatic scaling within the workload and deployment limits in your agreement	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.

See measurement rules, scaling and limits, and getting help.

Tensor9 BYOC

Getting Started

Self-Service Onboarding

How It Works

Deploying

Your Customer's Environment