Supported environments
- Akamai
- Azure
- DigitalOcean
- Google Cloud
- OCI
- Private Kubernetes
- Scaleway
How the targets compare
Each row compares a capability of EventBridge with its adaptation on each target. A dash means this profile does not state the capability for that target.Cloud Adapter
On Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway
PostgreSQL
Accepting and matching events
Tensor9 serves EventBridge APIs with PostgreSQL holding buses, rules, targets, accepted events and pending delivery work. Terraform declarations and authenticated API calls address the same records within an account. Configure the application client to use the EventBridge endpoint and credentials for the target environment. For each event on an existing bus, the adapter evaluates enabled rules on that bus and commits the event with one delivery record per matched rule and target. Two rules sharing a destination produce separate deliveries. Entries commit separately. A batch request can fail after earlier entries have committed, so retrying the batch can duplicate events. Destination delivery happens afterward. A nonexistent bus can return an event ID without storing or delivering the event. Confirm the bus exists before switching producers; an event ID alone does not establish durable work. The matcher evaluates nested objects, scalar and array values, the alternatives operator, prefix and suffix with their case-insensitive forms, equals-ignore-case, wildcard with escaped asterisks, numeric ranges, exists, IPv4 and IPv6 cidr, and anything-but with values, prefix, suffix, wildcard and case-insensitive forms. It runs in the adapter, so rules can inspect nested detail data without promoting it to broker attributes. Case-insensitive comparison folds Unicode letters as EventBridge does. Malformed patterns are refused with EventBridge’s reasons; a pattern that is not valid JSON receives a different message.Destination calls and payloads
Workers claim delivery records and call the configured destination. SQS, SNS and Lambda calls use signed service requests. Each destination needs a reachable endpoint and permission for its operation: SendMessage, Publish or InvokeFunction. Do not assume an SQS delivery role also grants SNS or Lambda access. Direct HTTP targets receive an unsigned POST; EventBridge Connections and managed API Destinations are outside this mapping. By default, a target receives the EventBridge envelope, including id, source, detail-type, time, region, account, resources and detail. A target can instead use constant Input, an InputPath selection or an InputTransformer template. Selection modes are mutually exclusive. JSON paths support the root, dotted members and nonnegative array indices. Unsupported path syntax is refused when configuring targets. Template variables must be declared; do not assume all AWS reserved variables are available. As in EventBridge, an InputPath that selects nothing delivers an empty JSON object, and a template variable whose path selects nothing renders as an empty value. Lambda calls first request asynchronous invocation. A receiver that explicitly refuses it uses synchronous fallback. With that fallback, function errors follow the EventBridge target retry policy, and Lambda asynchronous failure destinations do not apply. Deliveries in a claimed batch are sent concurrently, so a slow function does not hold the others in its batch, though the slowest send, up to a per-send deadline, delays the next batch.Recovery, retries and dead letters
Accepted delivery work survives a process restart. Work a stopped worker had claimed resumes when that claim expires, which can take up to about five minutes. A worker can retry after a lease expires, including when the destination accepted the preceding call but the worker failed before recording success. Delivery is at least once with no ordering guarantee. Use an application event key to make destination side effects safe to repeat. Each target can set its retry count and event-age limit. Age is measured from acceptance, rather than from the event’s supplied time. The default attempt budget differs from AWS. One target’s retry state is independent of another target’s success. Terminal dispatch failures with a configured SQS dead-letter queue record the failed delivery and pending dead-letter send in one database transaction. A separate worker sends the rendered target payload to that queue with EventBridge’s ERROR_CODE, ERROR_MESSAGE, RULE_ARN and TARGET_ARN message attributes, adding RETRY_ATTEMPTS and EXHAUSTED_RETRY_CONDITION when a retry or age limit ran out. ERROR_CODE carries EventBridge’s value for a destination 5xx, a permission refusal and a missing queue; other failures, including timeouts and throttling, are reported as UNKNOWN. Dead-letter arrival is asynchronous and can also be duplicated after a crash. Queue failures retry separately, but exhausting that budget leaves work requiring operator attention. A configured dead-letter queue is therefore not a guarantee that every failed event arrives there.Scheduled rules
A database-backed schedule driver creates the same durable work used for matched events. It supports rates and six-field UTC cron, including values, ranges that wrap, lists, steps, names, the question-mark day selector, explicit years, and the L, L-n, LW, nW, nL and n#k calendar forms. L-n selects no day in a month too short for it. Changing a rule’s expression schedules it afresh. PutRule validates expressions as EventBridge does and allows schedules only on the default bus. It also refuses a few forms EventBridge accepts whose firing times are undocumented: a step of zero, # on a range or on a day outside 1-7, W on a range, and L-n or a ranged L in the day-of-week field. A rate too long to schedule within the database’s calendar is accepted and never fires. Missed occurrences during downtime are not backfilled, and re-enabling a rule does not replay its disabled intervals. This mapping covers EventBridge scheduled rules; the separate EventBridge Scheduler service is outside its scope.Limitations
PutTargets refuses per-target RoleArn and service-specific parameter objects, including FIFO SqsParameters, ECS and HTTP parameters. A request containing an unsupported target field fails as a whole. Review the operation table before migrating those declarations. Workers resolve queued deliveries against target configuration when claiming work. Updating a target can change where pending work goes; an already claimed delivery may still use the previous configuration. Disabling a rule stops new matching but does not cancel accepted work. Drain pending deliveries before deleting and recreating a target with the same name. Event archives, replay, cross-account and cross-region routing, customer KMS keys per bus, Pipes and the schema registry are outside this mapping. Durable delivery records do not provide an application-facing event archive. Requests with unrecognized credentials receive HTTP 403, where EventBridge answers 400.Other considerations
Tensor9 operates the service adapter, matcher, delivery workers and scheduler. Database availability, backups and capacity follow the selected PostgreSQL deployment. Configure database access and destination permissions as part of the deployment, then check received payloads as well as successful PutEvents responses. Provision buses, rules and targets before switching producers. Existing AWS history and pending deliveries are not copied. Keep source destinations available while their pending work finishes. Monitor pending work, retries, terminal failures and failed dead-letter sends separately; a successful publish does not establish successful delivery.On Azure
PostgreSQL Flexible Server
PostgreSQL hosting
Microsoft operates Azure Database for PostgreSQL Flexible Server. The Cloud Adapter deployment provisions one server, injected into the Cloud Adapter deployment’s virtual network with no public endpoint, and every connection uses TLS. The PostgreSQL major version is fixed when the Cloud Adapter deployment is set up; Microsoft applies maintenance in its own window, which restarts the server. Automated backups keep seven days of history with point-in-time restore inside that window; geo-redundant backup is off. The server runs in a single availability zone without a zone-redundant standby, so a restart for maintenance or failure makes PutEvents return errors and stops delivery until the server returns. Committed events and pending deliveries are still there afterwards. EventBridge state lives in one database on that server. The SQS and SNS adapters on the same Cloud Adapter deployment use the same database when they run on PostgreSQL, and the Cloud Adapter deployment’s own state store is a separate database on the same server. Because an event bus declares no database size, the server has a fixed default size; connections, storage and throughput are shared limits, so watch them alongside pending delivery work. When the Cloud Adapter deployment is set up, the administrator password is generated and the connection string is stored in the Cloud Adapter deployment’s Azure Key Vault; the adapter’s identity can read that one secret and nothing else in the vault, and the application never handles it. Removing the Cloud Adapter deployment removes the server and the EventBridge state on it, so drain pending work first. Buses start empty, and existing AWS history is not migrated.Accepting and matching events
Tensor9 serves EventBridge APIs with PostgreSQL holding buses, rules, targets, accepted events and pending delivery work. Terraform declarations and authenticated API calls address the same records within an account. Configure the application client to use the EventBridge endpoint and credentials for the target environment. For each event on an existing bus, the adapter evaluates enabled rules on that bus and commits the event with one delivery record per matched rule and target. Two rules sharing a destination produce separate deliveries. Entries commit separately. A batch request can fail after earlier entries have committed, so retrying the batch can duplicate events. Destination delivery happens afterward. A nonexistent bus can return an event ID without storing or delivering the event. Confirm the bus exists before switching producers; an event ID alone does not establish durable work. The matcher evaluates nested objects, scalar and array values, the alternatives operator, prefix and suffix with their case-insensitive forms, equals-ignore-case, wildcard with escaped asterisks, numeric ranges, exists, IPv4 and IPv6 cidr, and anything-but with values, prefix, suffix, wildcard and case-insensitive forms. It runs in the adapter, so rules can inspect nested detail data without promoting it to broker attributes. Case-insensitive comparison folds Unicode letters as EventBridge does. Malformed patterns are refused with EventBridge’s reasons; a pattern that is not valid JSON receives a different message.Destination calls and payloads
Workers claim delivery records and call the configured destination. SQS, SNS and Lambda calls use signed service requests. Each destination needs a reachable endpoint and permission for its operation: SendMessage, Publish or InvokeFunction. Do not assume an SQS delivery role also grants SNS or Lambda access. Direct HTTP targets receive an unsigned POST; EventBridge Connections and managed API Destinations are outside this mapping. By default, a target receives the EventBridge envelope, including id, source, detail-type, time, region, account, resources and detail. A target can instead use constant Input, an InputPath selection or an InputTransformer template. Selection modes are mutually exclusive. JSON paths support the root, dotted members and nonnegative array indices. Unsupported path syntax is refused when configuring targets. Template variables must be declared; do not assume all AWS reserved variables are available. As in EventBridge, an InputPath that selects nothing delivers an empty JSON object, and a template variable whose path selects nothing renders as an empty value. Lambda calls first request asynchronous invocation. A receiver that explicitly refuses it uses synchronous fallback. With that fallback, function errors follow the EventBridge target retry policy, and Lambda asynchronous failure destinations do not apply. Deliveries in a claimed batch are sent concurrently, so a slow function does not hold the others in its batch, though the slowest send, up to a per-send deadline, delays the next batch.Recovery, retries and dead letters
Accepted delivery work survives a process restart. Work a stopped worker had claimed resumes when that claim expires, which can take up to about five minutes. A worker can retry after a lease expires, including when the destination accepted the preceding call but the worker failed before recording success. Delivery is at least once with no ordering guarantee. Use an application event key to make destination side effects safe to repeat. Each target can set its retry count and event-age limit. Age is measured from acceptance, rather than from the event’s supplied time. The default attempt budget differs from AWS. One target’s retry state is independent of another target’s success. Terminal dispatch failures with a configured SQS dead-letter queue record the failed delivery and pending dead-letter send in one database transaction. A separate worker sends the rendered target payload to that queue with EventBridge’s ERROR_CODE, ERROR_MESSAGE, RULE_ARN and TARGET_ARN message attributes, adding RETRY_ATTEMPTS and EXHAUSTED_RETRY_CONDITION when a retry or age limit ran out. ERROR_CODE carries EventBridge’s value for a destination 5xx, a permission refusal and a missing queue; other failures, including timeouts and throttling, are reported as UNKNOWN. Dead-letter arrival is asynchronous and can also be duplicated after a crash. Queue failures retry separately, but exhausting that budget leaves work requiring operator attention. A configured dead-letter queue is therefore not a guarantee that every failed event arrives there.Scheduled rules
A database-backed schedule driver creates the same durable work used for matched events. It supports rates and six-field UTC cron, including values, ranges that wrap, lists, steps, names, the question-mark day selector, explicit years, and the L, L-n, LW, nW, nL and n#k calendar forms. L-n selects no day in a month too short for it. Changing a rule’s expression schedules it afresh. PutRule validates expressions as EventBridge does and allows schedules only on the default bus. It also refuses a few forms EventBridge accepts whose firing times are undocumented: a step of zero, # on a range or on a day outside 1-7, W on a range, and L-n or a ranged L in the day-of-week field. A rate too long to schedule within the database’s calendar is accepted and never fires. Missed occurrences during downtime are not backfilled, and re-enabling a rule does not replay its disabled intervals. This mapping covers EventBridge scheduled rules; the separate EventBridge Scheduler service is outside its scope.Limitations
PutTargets refuses per-target RoleArn and service-specific parameter objects, including FIFO SqsParameters, ECS and HTTP parameters. A request containing an unsupported target field fails as a whole. Review the operation table before migrating those declarations. Workers resolve queued deliveries against target configuration when claiming work. Updating a target can change where pending work goes; an already claimed delivery may still use the previous configuration. Disabling a rule stops new matching but does not cancel accepted work. Drain pending deliveries before deleting and recreating a target with the same name. Event archives, replay, cross-account and cross-region routing, customer KMS keys per bus, Pipes and the schema registry are outside this mapping. Durable delivery records do not provide an application-facing event archive. Requests with unrecognized credentials receive HTTP 403, where EventBridge answers 400.Other considerations
Tensor9 operates the service adapter, matcher, delivery workers and scheduler. Database availability, backups and capacity follow the selected PostgreSQL deployment. Configure database access and destination permissions as part of the deployment, then check received payloads as well as successful PutEvents responses. Provision buses, rules and targets before switching producers. Existing AWS history and pending deliveries are not copied. Keep source destinations available while their pending work finishes. Monitor pending work, retries, terminal failures and failed dead-letter sends separately; a successful publish does not establish successful delivery.Azure Event Grid
Scope of this relation
EventBridge delivery through Azure Event Grid is outside this profile’s offered contract. Use the PostgreSQL service adapter for EventBridge buses, rules and durable target delivery. This comparison explains the native Event Grid mechanisms and their differences.Topics, filters and handlers
An Event Grid topic can represent events as CloudEvents. Event subscriptions apply advanced filters and deliver matches to handlers. Advanced filters support numeric and string conditions on supported fields, with syntax and limits that differ from EventBridge. A matching field name does not establish equivalent pattern behavior. An EventBridge mapping also needs an adapter for the EventBridge API and handlers that preserve target payload selection, destination permissions and delivery outcomes. Event Grid topic acceptance alone does not establish successful SQS, SNS or Lambda delivery.Limitations
Event Grid topic subscriptions use their own retry and event-age policies. Dead letters can be written to Blob Storage, which differs from an EventBridge target’s SQS dead-letter queue. See Event Grid delivery and retry for the native contract. Scheduled rules need a separate scheduler and destination delivery mechanism. Container Apps job schedules alone do not provide those EventBridge semantics. Scheduled rules, target transformations, archives, replay, Pipes and the schema registry are outside this mapping.Other considerations
Microsoft operates Event Grid topic storage and native delivery. Handlers still require authentication, network access and duplicate-safe processing. Review those responsibilities separately from the native broker’s retry policy when evaluating a migration.Container Apps
Scheduled-job configuration
This infrastructure translation turns supported EventBridge scheduled-rule declarations into Azure Container Apps Jobs. It covers the job’s schedule configuration. It provides no EventBridge request endpoint, event bus or scheduled target delivery. Use the PostgreSQL service adapter when the application needs EventBridge matching, publication and delivery. A job schedule alone does not send the scheduled event to SQS.Cron and rate translation
Container Apps scheduled jobs use five-field cron in UTC. The translation handles representable AWS six-field cron and rate expressions and rejects expressions it cannot preserve. Review the emitted schedule and allow for job startup time; a scheduled trigger does not guarantee immediate processing. See Container Apps jobs for the native scheduling and execution model.Limitations
Deployment refuses event-pattern rules, non-SQS target declarations and target input overrides, including constant input, input paths and transformers. Accepting an SQS target declaration does not establish target delivery. EventBridge retry and dead-letter delivery are outside this mapping. Container Apps job retries and SQS queue redrive are separate policies. Archives, replay, Pipes, the schema registry and cross-account bus routing are also outside scope.Other considerations
Microsoft operates job execution. Estimate compute use from schedule frequency, run duration and allocated resources. Application processing needs its own executable, destination credentials and network access; these responsibilities are separate from schedule translation.On Google Cloud
Cloud SQL for PostgreSQL
PostgreSQL hosting
Google operates Cloud SQL for PostgreSQL. The Cloud Adapter deployment provisions one instance with no public IP address, reached only through a Private Service Connect endpoint inside the Cloud Adapter deployment’s network, and every connection uses TLS. The PostgreSQL major version is fixed when the Cloud Adapter deployment is set up; Google applies maintenance in its own window, which restarts the instance. Daily automated backups run with point-in-time recovery, keeping seven days of transaction logs and seven backups. The instance runs in a single zone without a regional standby, so a restart for maintenance or failure makes PutEvents return errors and stops delivery until the instance returns. Committed events and pending deliveries are still there afterwards. EventBridge state lives in one database on that instance. The SQS and SNS adapters on the same Cloud Adapter deployment use the same database when they run on PostgreSQL, and the Cloud Adapter deployment’s own state store is a separate database on the same instance. Because an event bus declares no database size, the instance has a fixed, shared-core default machine size; connections, storage and throughput are shared limits, so watch them alongside pending delivery work. When the Cloud Adapter deployment is set up, a dedicated database user and password are generated and the connection string is stored in the Cloud Adapter deployment’s Secret Manager, where the adapter resolves it; the application never handles it. Removing the Cloud Adapter deployment removes the instance and the EventBridge state on it, so drain pending work first. Buses start empty, and existing AWS history is not migrated.Accepting and matching events
Tensor9 serves EventBridge APIs with PostgreSQL holding buses, rules, targets, accepted events and pending delivery work. Terraform declarations and authenticated API calls address the same records within an account. Configure the application client to use the EventBridge endpoint and credentials for the target environment. For each event on an existing bus, the adapter evaluates enabled rules on that bus and commits the event with one delivery record per matched rule and target. Two rules sharing a destination produce separate deliveries. Entries commit separately. A batch request can fail after earlier entries have committed, so retrying the batch can duplicate events. Destination delivery happens afterward. A nonexistent bus can return an event ID without storing or delivering the event. Confirm the bus exists before switching producers; an event ID alone does not establish durable work. The matcher evaluates nested objects, scalar and array values, the alternatives operator, prefix and suffix with their case-insensitive forms, equals-ignore-case, wildcard with escaped asterisks, numeric ranges, exists, IPv4 and IPv6 cidr, and anything-but with values, prefix, suffix, wildcard and case-insensitive forms. It runs in the adapter, so rules can inspect nested detail data without promoting it to broker attributes. Case-insensitive comparison folds Unicode letters as EventBridge does. Malformed patterns are refused with EventBridge’s reasons; a pattern that is not valid JSON receives a different message.Destination calls and payloads
Workers claim delivery records and call the configured destination. SQS, SNS and Lambda calls use signed service requests. Each destination needs a reachable endpoint and permission for its operation: SendMessage, Publish or InvokeFunction. Do not assume an SQS delivery role also grants SNS or Lambda access. Direct HTTP targets receive an unsigned POST; EventBridge Connections and managed API Destinations are outside this mapping. By default, a target receives the EventBridge envelope, including id, source, detail-type, time, region, account, resources and detail. A target can instead use constant Input, an InputPath selection or an InputTransformer template. Selection modes are mutually exclusive. JSON paths support the root, dotted members and nonnegative array indices. Unsupported path syntax is refused when configuring targets. Template variables must be declared; do not assume all AWS reserved variables are available. As in EventBridge, an InputPath that selects nothing delivers an empty JSON object, and a template variable whose path selects nothing renders as an empty value. Lambda calls first request asynchronous invocation. A receiver that explicitly refuses it uses synchronous fallback. With that fallback, function errors follow the EventBridge target retry policy, and Lambda asynchronous failure destinations do not apply. Deliveries in a claimed batch are sent concurrently, so a slow function does not hold the others in its batch, though the slowest send, up to a per-send deadline, delays the next batch.Recovery, retries and dead letters
Accepted delivery work survives a process restart. Work a stopped worker had claimed resumes when that claim expires, which can take up to about five minutes. A worker can retry after a lease expires, including when the destination accepted the preceding call but the worker failed before recording success. Delivery is at least once with no ordering guarantee. Use an application event key to make destination side effects safe to repeat. Each target can set its retry count and event-age limit. Age is measured from acceptance, rather than from the event’s supplied time. The default attempt budget differs from AWS. One target’s retry state is independent of another target’s success. Terminal dispatch failures with a configured SQS dead-letter queue record the failed delivery and pending dead-letter send in one database transaction. A separate worker sends the rendered target payload to that queue with EventBridge’s ERROR_CODE, ERROR_MESSAGE, RULE_ARN and TARGET_ARN message attributes, adding RETRY_ATTEMPTS and EXHAUSTED_RETRY_CONDITION when a retry or age limit ran out. ERROR_CODE carries EventBridge’s value for a destination 5xx, a permission refusal and a missing queue; other failures, including timeouts and throttling, are reported as UNKNOWN. Dead-letter arrival is asynchronous and can also be duplicated after a crash. Queue failures retry separately, but exhausting that budget leaves work requiring operator attention. A configured dead-letter queue is therefore not a guarantee that every failed event arrives there.Scheduled rules
A database-backed schedule driver creates the same durable work used for matched events. It supports rates and six-field UTC cron, including values, ranges that wrap, lists, steps, names, the question-mark day selector, explicit years, and the L, L-n, LW, nW, nL and n#k calendar forms. L-n selects no day in a month too short for it. Changing a rule’s expression schedules it afresh. PutRule validates expressions as EventBridge does and allows schedules only on the default bus. It also refuses a few forms EventBridge accepts whose firing times are undocumented: a step of zero, # on a range or on a day outside 1-7, W on a range, and L-n or a ranged L in the day-of-week field. A rate too long to schedule within the database’s calendar is accepted and never fires. Missed occurrences during downtime are not backfilled, and re-enabling a rule does not replay its disabled intervals. This mapping covers EventBridge scheduled rules; the separate EventBridge Scheduler service is outside its scope.Limitations
PutTargets refuses per-target RoleArn and service-specific parameter objects, including FIFO SqsParameters, ECS and HTTP parameters. A request containing an unsupported target field fails as a whole. Review the operation table before migrating those declarations. Workers resolve queued deliveries against target configuration when claiming work. Updating a target can change where pending work goes; an already claimed delivery may still use the previous configuration. Disabling a rule stops new matching but does not cancel accepted work. Drain pending deliveries before deleting and recreating a target with the same name. Event archives, replay, cross-account and cross-region routing, customer KMS keys per bus, Pipes and the schema registry are outside this mapping. Durable delivery records do not provide an application-facing event archive. Requests with unrecognized credentials receive HTTP 403, where EventBridge answers 400.Other considerations
Tensor9 operates the service adapter, matcher, delivery workers and scheduler. Database availability, backups and capacity follow the selected PostgreSQL deployment. Configure database access and destination permissions as part of the deployment, then check received payloads as well as successful PutEvents responses. Provision buses, rules and targets before switching producers. Existing AWS history and pending deliveries are not copied. Keep source destinations available while their pending work finishes. Monitor pending work, retries, terminal failures and failed dead-letter sends separately; a successful publish does not establish successful delivery.Pub/Sub
Scope of this relation
EventBridge delivery through Google Cloud Pub/Sub is outside this profile’s offered contract. Use the PostgreSQL service adapter for EventBridge buses, rules and durable target delivery. This comparison explains the native Pub/Sub mechanisms and the differences that matter when evaluating an EventBridge mapping.Topics, filters and destination delivery
A Pub/Sub topic is the natural counterpart of an event bus, with subscriptions selecting messages for consumers. Pub/Sub filters inspect message attributes, not the message body. Promoting source and detail-type to attributes can express simple conditions; nested EventBridge detail matching requires additional processing. See Pub/Sub message filtering. An EventBridge mapping also needs a service adapter to accept PutEvents and manage rules, plus workers that apply target input selection and call authorized destinations. A broker’s acknowledgment is distinct from completion of that destination call.Limitations
Native subscription redelivery and dead-letter topics do not establish EventBridge per-target retry, event-age or SQS dead-letter semantics. A separate scheduler, such as Cloud Scheduler, would also need to preserve rule timing and destination behavior. These capabilities are outside this mapping, as are archives, replay, Pipes and the schema registry.Other considerations
Google operates Pub/Sub storage and subscription redelivery. Application consumers still need authentication, network access and duplicate-safe processing. Evaluate native Pub/Sub with those responsibilities in view; its broker features alone do not establish EventBridge API compatibility or target delivery.Service level agreements
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.EventBridge to Container Apps
SLA status: Not applicable 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 to Azure Event Grid
SLA status: Not applicable 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 to PostgreSQL Flexible Server
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Forazure::1.0.0::postgresql::flexible, the SLA separates event acceptance from delivery. The PostgreSQL-backed adapter persists events, evaluates enabled patterns and records one delivery task per matched target. Workers and the scheduler create and drain durable work separately. A slow destination can delay its delivery without slowing the producer’s acceptance response; slow adapter-owned rule lookup or delivery bookkeeping still counts as fabric time.
How the latency targets were chosen
Bounded event acceptance and matching: 25 ms monthly p99.PutEvents. The PostgreSQL engine matches rules in-process and commits delivery-outbox work before acceptance. Rule lookup, matching, input transformation and adapter-owned outbox writes all count.
Bus, rule and target configuration: 20 ms monthly p99. CreateEventBus, DeleteEventBus, DeleteRule, DescribeEventBus, DescribeRule, DisableRule, EnableRule, ListEventBuses, ListRules, ListTargetsByRule, PutRule, PutTargets, RemoveTargets. Durable catalog changes, pattern validation and target authorization precede the response; those metadata waits remain fabric work.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Matching cost grows with events times rules, and delivery work grows with matched rules times targets. Scale handler CPU and delivery workers using both dimensions; watch delivery backlog and database connection pressure. The numeric request row deliberately bounds rules and fan-out. A customer with 2,000 rules needs a different envelope, not an assumption that more replicas eliminate per-event matching cost. Destination capacity and the customer’s retry/DLQ configuration remain separate. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
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.Example and diagnosis
For busorder-events, submit five 2 KiB events with ten enabled rules and three targets per matching rule. This fits the acceptance row. Diagnose a slow producer by looking at catalog lookup, matching and outbox commit; diagnose a late consumer using delivery backlog and target errors. A fast PutEvents response alone does not prove delivery is healthy.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
EventBridge to Cloud SQL for PostgreSQL
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Forgoogle::1.0.0::cloudsql::postgresql, the SLA separates event acceptance from delivery. The PostgreSQL-backed adapter persists events, evaluates enabled patterns and records one delivery task per matched target. Workers and the scheduler create and drain durable work separately. A slow destination can delay its delivery without slowing the producer’s acceptance response; slow adapter-owned rule lookup or delivery bookkeeping still counts as fabric time.
How the latency targets were chosen
Bounded event acceptance and matching: 25 ms monthly p99.PutEvents. The PostgreSQL engine matches rules in-process and commits delivery-outbox work before acceptance. Rule lookup, matching, input transformation and adapter-owned outbox writes all count.
Bus, rule and target configuration: 20 ms monthly p99. CreateEventBus, DeleteEventBus, DeleteRule, DescribeEventBus, DescribeRule, DisableRule, EnableRule, ListEventBuses, ListRules, ListTargetsByRule, PutRule, PutTargets, RemoveTargets. Durable catalog changes, pattern validation and target authorization precede the response; those metadata waits remain fabric work.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Matching cost grows with events times rules, and delivery work grows with matched rules times targets. Scale handler CPU and delivery workers using both dimensions; watch delivery backlog and database connection pressure. The numeric request row deliberately bounds rules and fan-out. A customer with 2,000 rules needs a different envelope, not an assumption that more replicas eliminate per-event matching cost. Destination capacity and the customer’s retry/DLQ configuration remain separate. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
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.Example and diagnosis
For busorder-events, submit five 2 KiB events with ten enabled rules and three targets per matching rule. This fits the acceptance row. Diagnose a slow producer by looking at catalog lookup, matching and outbox commit; diagnose a late consumer using delivery backlog and target errors. A fast PutEvents response alone does not prove delivery is healthy.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
EventBridge to Pub/Sub
SLA status: Not applicable 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.EventBridge to PostgreSQL
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Forpostgres::1.0.0::database, the SLA separates event acceptance from delivery. The PostgreSQL-backed adapter persists events, evaluates enabled patterns and records one delivery task per matched target. Workers and the scheduler create and drain durable work separately. A slow destination can delay its delivery without slowing the producer’s acceptance response; slow adapter-owned rule lookup or delivery bookkeeping still counts as fabric time.
How the latency targets were chosen
Bounded event acceptance and matching: 25 ms monthly p99.PutEvents. The PostgreSQL engine matches rules in-process and commits delivery-outbox work before acceptance. Rule lookup, matching, input transformation and adapter-owned outbox writes all count.
Bus, rule and target configuration: 20 ms monthly p99. CreateEventBus, DeleteEventBus, DeleteRule, DescribeEventBus, DescribeRule, DisableRule, EnableRule, ListEventBuses, ListRules, ListTargetsByRule, PutRule, PutTargets, RemoveTargets. Durable catalog changes, pattern validation and target authorization precede the response; those metadata waits remain fabric work.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Matching cost grows with events times rules, and delivery work grows with matched rules times targets. Scale handler CPU and delivery workers using both dimensions; watch delivery backlog and database connection pressure. The numeric request row deliberately bounds rules and fan-out. A customer with 2,000 rules needs a different envelope, not an assumption that more replicas eliminate per-event matching cost. Destination capacity and the customer’s retry/DLQ configuration remain separate. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
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.Example and diagnosis
For busorder-events, submit five 2 KiB events with ten enabled rules and three targets per matching rule. This fits the acceptance row. Diagnose a slow producer by looking at catalog lookup, matching and outbox commit; diagnose a late consumer using delivery backlog and target errors. A fast PutEvents response alone does not prove delivery is healthy.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Install and run
The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. SetT9_API_KEY as described in Install and Authenticate, then list the adapters your account may use with this origin: