> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# EventBridge

> EventBridge APIs with Cloud Adapter.

Preview

This page describes how EventBridge maps to services in the environment where the application runs, including backend choices, supported operations and service-specific behavior.

## Supported environments

* Akamai
* Azure
* DigitalOcean
* Google Cloud
* OCI
* Private Kubernetes
* Scaleway

Check the operation and capability tables for the behavior your application depends on. A supported environment does not imply that every operation of the origin service is available.

## How the backends compare

Each row compares a capability of EventBridge with its adaptation on each backend.
A dash means this profile does not state the capability for that backend.

### Cloud Adapter

| Capability | EventBridge | Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway · PostgreSQL | Azure · PostgreSQL Flexible Server | Azure · Azure Event Grid | Azure · Container Apps | Google Cloud · Cloud SQL for PostgreSQL | Google Cloud · Pub/Sub |
| - | - | - | - | - | - | - | - |
| Event bus + PutEvents | native | EventBridge API with PostgreSQL persistence | EventBridge API with PostgreSQL persistence | Outside the offered EventBridge contract | - | EventBridge API with PostgreSQL persistence | Outside the offered EventBridge contract |
| Event-pattern matching | Yes | Partial - Nested detail, \$or and EventBridge content filters, checked against EventBridge's own answers | Partial - Nested detail, \$or and EventBridge content filters, checked against EventBridge's own answers | No - Event Grid advanced filters cover numeric and string conditions on supported fields, with their own syntax and limits. They do not cover the complete EventBridge pattern language. | - | Partial - Nested detail, \$or and EventBridge content filters, checked against EventBridge's own answers | No - Pub/Sub filters message attributes, not the message body. Promoting source and detail-type to attributes can cover simple rules; nested EventBridge detail matching needs additional processing. |
| Scheduled rules · cron / rate | native | Rates and six-field UTC cron, refusing a few forms with undocumented timing; no missed-occurrence backfill | Rates and six-field UTC cron, refusing a few forms with undocumented timing; no missed-occurrence backfill | Outside this mapping | - | Rates and six-field UTC cron, refusing a few forms with undocumented timing; no missed-occurrence backfill | Outside this mapping |
| Rule targets · fan-out | SQS / SNS / Lambda / … | Separate durable work per rule and target; authorized SQS, SNS, Lambda and unsigned HTTP delivery | Separate durable work per rule and target; authorized SQS, SNS, Lambda and unsigned HTTP delivery | Outside this mapping | - | Separate durable work per rule and target; authorized SQS, SNS, Lambda and unsigned HTTP delivery | Outside this mapping |
| Target DLQ + retry | Yes | Partial - Per-target retry and age limits; asynchronous SQS dead-letter handoff with separate retries and possible duplicates | Partial - Per-target retry and age limits; asynchronous SQS dead-letter handoff with separate retries and possible duplicates | No - Event Grid topic subscriptions have native retry and event-age policies and can dead-letter to Blob Storage. That does not implement an EventBridge target's SQS dead-letter contract. | - | Partial - Per-target retry and age limits; asynchronous SQS dead-letter handoff with separate retries and possible duplicates | No - Pub/Sub subscription redelivery and dead-letter topics have different semantics from EventBridge target retries and an SQS dead-letter queue. They do not establish destination success or EventBridge event-age limits. |
| API coverage | full | high | high | minimal | partial | high | minimal |
| Durability · backups + cluster rebuild | AWS-managed regional service | - | buses, rules, events and pending deliveries persist on the Microsoft-operated server outside the Cloud Adapter deployment cluster, with automated backups with a seven-day retention window and point-in-time restore inside it; a cluster rebuild does not lose them | - | - | buses, rules, events and pending deliveries persist on the Google-operated instance outside the Cloud Adapter deployment cluster, with daily automated backups with point-in-time recovery over seven days of transaction logs; a cluster rebuild does not lose them | - |
| Availability · server restarts | AWS-managed | - | one server in a single availability zone with no zone-redundant standby; during a maintenance or failure restart PutEvents returns errors and delivery stops, and committed work resumes when the server returns | - | - | - | - |
| Shared database · one server per Cloud Adapter deployment | dedicated service | - | one Flexible Server per Cloud Adapter deployment at a fixed default size, because an event bus declares no database size; EventBridge state shares its database with the SQS and SNS adapters the same Cloud Adapter deployment serves on PostgreSQL, so their load shares the server's connection, storage and throughput limits | - | - | - | - |
| Availability · instance restarts | AWS-managed | - | - | - | - | one instance in a single zone with no regional standby; during a maintenance or failure restart PutEvents returns errors and delivery stops, and committed work resumes when the instance returns | - |
| Shared database · one instance per Cloud Adapter deployment | dedicated service | - | - | - | - | one Cloud SQL instance per Cloud Adapter deployment at a fixed, dedicated 1-vCPU, 6-GiB default machine size, because an event bus declares no database size; EventBridge state shares its database with the SQS and SNS adapters the same Cloud Adapter deployment serves on PostgreSQL, so their load shares the instance's connection, storage and throughput limits | - |

## On Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway

### PostgreSQL

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Cross-account / cross-region buses | Bus | Out of scope | Full surface | Cross-account and cross-region bus routing is outside this mapping. |
| Event bus (default + custom) | Bus | Partial | Common | Terraform bus, rule and target declarations and EventBridge API calls use the same PostgreSQL records within the authenticated account. Custom buses are stored durably; the default bus is available per account. Bus tags are stored, by Terraform declaration and by CreateEventBus alike, but are not readable through the API: DescribeEventBus returns name and ARN as EventBridge does, and TagResource, UntagResource and ListTagsForResource are not served. Both doors refuse the same bus fields: CreateEventBus answers ValidationException for KmsKeyIdentifier, DeadLetterConfig, Description, EventSourceName and LogConfig, and a Terraform declaration that sets any of them fails the compile rather than applying without them: a customer-managed encryption key or a bus-level dead letter is not served here, and accepting the field would report a control that is not in force. Across the control plane, any request field an operation does not implement is refused by name rather than ignored; pagination keys are the exception, accepted and ignored because every list returns its whole set in one response. |
| Event bus SSE (customer KMS key) | Bus | Out of scope | Full surface | A customer-managed KMS key per bus is unsupported. Configure encryption on the backing store. |
| Schema registry / EventBridge Pipes | Ecosystem | Out of scope | Full surface | The schema registry and EventBridge Pipes are separate services outside this mapping. |
| PutEvents | Publish | Partial | Common | On an existing bus, each event and its matched rule-target delivery records commit in one transaction. Entries commit separately; a request failure can follow earlier commits, so retrying the batch can duplicate events. A nonexistent bus returns an event ID without storing or delivering the event, as EventBridge does. Confirm the bus exists before switching producers. Entries are validated as EventBridge validates them, and each refused entry is reported with EventBridge's error code while the rest of the batch is accepted. A bus can be named by ARN within the calling account and Region. PutEvents refuses EndpointId with ValidationException rather than dropping it: it names a global endpoint, so accepting it would report success for events that went to the local bus instead. TraceHeader is accepted and not propagated; there is no X-Ray here to correlate against. |
| Archive + replay | Replay | Out of scope | Full surface | Event archives and time-range replay are outside this mapping. |
| Rule: event pattern (JSON matcher) | Rules | Partial | Common | The adapter evaluates nested detail fields, \$or, prefix and suffix (including their case-insensitive forms), equals-ignore-case, wildcard with escaped asterisks, anything-but with values, prefix, suffix, wildcard and case-insensitive forms, numeric ranges, exists, and IPv4 and IPv6 cidr. 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. Check each operator used by the application. On every PutRule, pattern or scheduled, RoleArn and Tags are refused with ValidationException rather than dropped, and a Terraform rule declaring either fails the compile -- rule tags and a rule-level role are not stored -- and State accepts ENABLED and DISABLED only: ENABLED\_WITH\_ALL\_CLOUDTRAIL\_MANAGEMENT\_EVENTS is refused because this Cloud Adapter deployment has no CloudTrail management-event stream. |
| Rule: scheduled (cron / rate) | Rules | Partial | Most usage | Rates and six-field UTC cron produce durable delivery work. Cron supports values, lists, ranges including wrapping ranges, steps, names, ?, L, L-n, LW, nW, nL and n#k, with explicit years. L-n selects no day in a month too short for it. PutRule refuses the expressions EventBridge refuses, and also refuses a few forms EventBridge accepts but whose firing times are undocumented: a step of zero, # on a range or a day outside 1-7, W on a range, and L-n or ranged L in day-of-week. Schedules are allowed only on the default bus. Missed occurrences are not backfilled. This covers scheduled rules, not the separate EventBridge Scheduler service. |
| DLQ + retry policy on targets | Targets | Partial | Most usage | Retries use each target's attempt and event-age limits; age starts at acceptance. Delivery is at least once. Terminal dispatch failures can record durable work for an SQS dead-letter queue, whose sends retry separately and can also produce duplicates. The queue receives the rendered target payload with EventBridge's ERROR\_CODE, ERROR\_MESSAGE, RULE\_ARN and TARGET\_ARN attributes, plus RETRY\_ATTEMPTS and EXHAUSTED\_RETRY\_CONDITION when a retry or age limit was reached. ERROR\_CODE uses EventBridge's value for a destination 5xx, a permission refusal and a missing queue; every other failure, including timeouts and throttling, is reported as UNKNOWN. Exhausted dead-letter sends need operator attention; a configured queue does not guarantee that every failure reaches it. Lambda synchronous fallback uses this policy instead of Lambda asynchronous failure destinations. |
| Target input (constant / input\_path / transformer) | Targets | Partial | Full surface | Targets receive the event envelope, constant Input, an InputPath selection or an InputTransformer result. JSON paths support the root, dotted members and nonnegative array indices. Wildcards, filters, slices, recursive descent and quoted members are refused. Template variables must be declared; AWS reserved-variable coverage differs. As in EventBridge, an InputPath that selects nothing delivers \{}, and a transformer variable whose path selects nothing renders as an empty value. |
| Targets (fan a rule to N targets) | Targets | Partial | Common | Each matched rule-target pair has independent delivery work, including rules sharing a destination. SQS, SNS and Lambda require configured endpoints and permission to call the destination. PutTargets refuses a target of a supported type that this Cloud Adapter deployment has no delivery endpoint configured for, naming the type, the types it does deliver to and the endpoint setting to add; nothing is stored. Terraform apply does not yet apply that check -- a target declared that way is stored and its deliveries then fail and dead-letter -- so confirm with your operator that an endpoint is configured for each type you declare; the Cloud Adapter deployment startup log names each type it has none for. HTTP targets receive an unsigned POST; EventBridge Connections and API Destinations are outside this mapping. Lambda receivers that refuse asynchronous invocation use synchronous fallback, with function failures handled by the EventBridge retry policy. PutTargets refuses RoleArn, EcsParameters, SqsParameters, HttpParameters, KinesisParameters, BatchParameters, RedshiftDataParameters, SageMakerPipelineParameters, AppSyncParameters and RunCommandParameters with ValidationException; the whole request fails without storing its targets. A target ARN naming any other destination service -- Step Functions, Kinesis, ECS and the rest of the EventBridge target catalogue -- is refused the same way, by PutTargets and by Terraform apply alike, naming the destination and the supported types. AWS accepts those targets, so this is a deliberate difference: the alternative is accepting a target that no worker can ever deliver to. |

#### Accepting and matching events

The Tensor9 adapter provides the EventBridge API, and PostgreSQL stores your buses, rules, targets, accepted events and the deliveries still to be made. Terraform declarations and authenticated API calls work on the same records within an account. Point the application's EventBridge client at the adapter's endpoint, with the target environment's credentials.

For each event sent to an existing bus, the adapter evaluates the bus's enabled rules and saves the event together with one pending delivery per matched rule and target, so two rules with the same destination produce two deliveries. Each entry in a batch is saved on its own: a batch request can fail after earlier entries were saved, so retrying the whole batch can duplicate events. Delivery to destinations happens afterward.

An event sent to a bus that does not exist can still receive an event ID, but it is neither stored nor delivered. Confirm the bus exists before switching producers; an event ID alone does not mean the event was saved.

Event patterns support 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. Matching runs in the adapter, so rules can inspect nested detail fields directly. Case-insensitive matching folds Unicode letters as EventBridge does. A malformed pattern is rejected with EventBridge's reason; a pattern that is not valid JSON gets a different message.

#### Destination calls and payloads

Delivery workers pick up pending deliveries and call each target. SQS, SNS and Lambda calls are signed AWS requests, so each destination needs a reachable endpoint and permission for its operation: `SendMessage`, `Publish` or `InvokeFunction`. Permission to deliver to SQS does not imply SNS or Lambda access. HTTP targets receive an unsigned POST; EventBridge Connections and API destinations are not part of this mapping.

By default a target receives the EventBridge envelope: id, source, detail-type, time, region, account, resources and detail. A target can instead use a constant `Input`, an `InputPath` selection or an `InputTransformer` template, but only one of them. JSON paths support the root, dotted members and non-negative array indexes; other path syntax is rejected when you configure the target. Template variables must be declared, and not every AWS reserved variable is available. As in EventBridge, an `InputPath` that selects nothing delivers an empty JSON object, and a template variable that selects nothing renders as an empty value.

Lambda targets are invoked asynchronously first. If the function rejects asynchronous invocation, the worker falls back to a synchronous call; function errors then follow the target's EventBridge retry policy, and Lambda's asynchronous failure destinations do not apply. Deliveries in one batch are sent concurrently, so a slow function does not hold up the others in its batch, but the slowest send, up to a per-send time limit, delays the next batch.

#### Retries, duplicates and dead letters

Pending deliveries survive a restart. Deliveries a stopped worker had picked up resume when its lease expires, which can take up to about five minutes. A worker can retry after a lease expires even if the destination accepted the earlier call but the worker stopped before recording success. Delivery is therefore at least once, with no ordering guarantee; use an event key in your application to make repeated deliveries harmless.

Each target can set its retry count and maximum event age. Age is measured from when the adapter accepted the event, not from the event's own time field. The default number of attempts differs from AWS. One target's retries do not depend on another target's success.

When a delivery fails for good and the target has an SQS dead-letter queue, the failure and the pending dead-letter send are saved together in one database transaction. A separate worker then sends the target's rendered payload to that queue with EventBridge's `ERROR_CODE`, `ERROR_MESSAGE`, `RULE_ARN` and `TARGET_ARN` message attributes, plus `RETRY_ATTEMPTS` and `EXHAUSTED_RETRY_CONDITION` when a retry or age limit ran out. `ERROR_CODE` holds EventBridge's value for a destination 5xx error, a permission error and a missing queue; other failures, including timeouts and throttling, are reported as `UNKNOWN`. Dead-letter messages arrive asynchronously and can be duplicated after a crash. Sends to the dead-letter queue are retried separately, and a send that exhausts those retries needs operator attention, so a dead-letter queue does not guarantee that every failed event arrives there.

#### Scheduled rules

Scheduled rules create the same saved deliveries as matched events. Rate expressions and six-field UTC cron are supported, including values, ranges that wrap, lists, steps, names, the `?` 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 rejects a few forms EventBridge accepts but 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 for the database's calendar is accepted but never fires. Occurrences missed during downtime are not run later, and re-enabling a rule does not replay the time it was disabled. The separate EventBridge Scheduler service is not part of this mapping.

#### Limitations

* **Per-target `RoleArn` and service-specific parameters are not supported.** `PutTargets` rejects them, including FIFO `SqsParameters`, ECS and HTTP parameters, and a request with any unsupported target field fails as a whole. Check the operation table before migrating those declarations. - **Target updates behave differently: pending deliveries follow the new configuration.** Workers read a target's configuration when they pick up a delivery, so updating a target can redirect pending work; a delivery already picked up may still use the old configuration. - **Disabling a rule behaves differently: saved deliveries still go out.** It stops new matching but does not cancel accepted work. Drain pending deliveries before deleting and re-creating a target with the same name. - **Archives, replay, cross-account and cross-region routing, per-bus customer KMS keys, Pipes and the schema registry are not supported.** The saved delivery records are not an event archive your application can read. - **Unrecognized credentials behave differently: they get HTTP 403.** EventBridge answers 400.

#### Other considerations

**Who runs what.** Tensor9 operates the adapter, matcher, delivery workers and scheduler. Database availability, backups and capacity depend on the PostgreSQL deployment you choose. Set up database access and destination permissions with the deployment.

**Before switching producers.** Create buses, rules and targets first. AWS event history and pending deliveries are not copied, so keep the old destinations available until their pending work finishes. Check the payloads your targets receive, not only successful `PutEvents` responses.

**What to monitor.** Track pending deliveries, retries, permanent failures and failed dead-letter sends separately; a successful publish does not mean the event was delivered.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### EventBridge · Custom event units

Feature: EventBridge.

Estimated monthly service charges by Custom event units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/8b1c6d26855e17e879452a664955d1ac1956a052dc0da53b0fee2d3d355c4890-light.svg)

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/c2b3e04f17376aed265900b2264b680ed8d0a83bbbe785f8c1b746a02583e2e9-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Custom event units (per second) | EventBridge | Target scenario | PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL (one copy) | 80.90 | 80.90 |
| 0 | 0.00 | PostgreSQL (two copies) | 161.79 | 161.79 |
| 1 | 2.63 | PostgreSQL (one copy) | 80.90 | 78.27 |
| 1 | 2.63 | PostgreSQL (two copies) | 161.79 | 159.16 |
| 10 | 26.28 | PostgreSQL (one copy) | 80.90 | 54.62 |
| 10 | 26.28 | PostgreSQL (two copies) | 161.79 | 135.51 |
| 100 | 262.80 | PostgreSQL (one copy) | 80.90 | -181.90 |
| 100 | 262.80 | PostgreSQL (two copies) | 161.79 | -101.01 |
| 1,000 | 2,628.00 | PostgreSQL (one copy) | 577.17 | -2,050.83 |
| 1,000 | 2,628.00 | PostgreSQL (two copies) | 1,154.34 | -1,473.66 |
| 10,000 | 26,280.00 | PostgreSQL (one copy) | 4,547.35 | -21,732.65 |
| 10,000 | 26,280.00 | PostgreSQL (two copies) | 9,094.71 | -17,185.29 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 128 vCPU, 512 GiB memory and 100 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| PostgreSQL (one copy) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| PostgreSQL (one copy) | Representative event size | 1,024 | bytes |
| PostgreSQL (one copy) | Rules evaluated per event | 10 | rules |
| PostgreSQL (one copy) | Point-read work equivalent per rule | 0.1 | operations |
| PostgreSQL (one copy) | Matched targets per event | 1 | targets |
| PostgreSQL (one copy) | Delivery attempts | 1 | attempts/target |
| PostgreSQL (one copy) | Outbox residence window | 60 | seconds |
| PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| PostgreSQL (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (one copy) | Approximate target service minimum | 0 | USD/month |
| PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL (two copies) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| PostgreSQL (two copies) | Representative event size | 1,024 | bytes |
| PostgreSQL (two copies) | Rules evaluated per event | 10 | rules |
| PostgreSQL (two copies) | Point-read work equivalent per rule | 0.1 | operations |
| PostgreSQL (two copies) | Matched targets per event | 1 | targets |
| PostgreSQL (two copies) | Delivery attempts | 1 | attempts/target |
| PostgreSQL (two copies) | Outbox residence window | 60 | seconds |
| PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| PostgreSQL (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (two copies) | Approximate target service minimum | 0 | USD/month |
| PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Rules evaluated, matched targets and retries remain explicit. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.
* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.
* Self-hosted target: PostgreSQL (PostgreSQL License, [https://www.postgresql.org/about/licence/](https://www.postgresql.org/about/licence/)). Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Compute Engine n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/compute/docs/general-purpose-machines](https://docs.cloud.google.com/compute/docs/general-purpose-machines)); a Persistent Disk volume holds up to 64 TiB ([https://docs.cloud.google.com/compute/docs/disks/persistent-disks](https://docs.cloud.google.com/compute/docs/disks/persistent-disks)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AWSEvents offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json)
* Compute Engine general-purpose machine pricing: [https://cloud.google.com/products/compute/pricing/general-purpose](https://cloud.google.com/products/compute/pricing/general-purpose)
* Disk and image pricing: [https://cloud.google.com/compute/disks-image-pricing](https://cloud.google.com/compute/disks-image-pricing)
* Network pricing: [https://cloud.google.com/vpc/network-pricing](https://cloud.google.com/vpc/network-pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-1b3d195812060b0f8a3f49a7665e8f1d793b512b` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing).

**EventBridge → PostgreSQL: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Custom event ingestion | 0.00 |
| Target: Provisioned primary CPU | 46.15 |
| Target: Provisioned primary RAM | 24.74 |
| Target: Provisioned primary disk | 10.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent provisioned resources | 0.00 |
| Target: Independent managed resources | 0.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **80.90** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Representative event size | 1,024 | bytes |
| Rules evaluated per event | 10 | rules |
| Point-read work equivalent per rule | 0.1 | operations |
| Matched targets per event | 1 | targets |
| Delivery attempts | 1 | attempts/target |
| Outbox residence window | 60 | seconds |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.1 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0.12 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Custom event ingestion | 0 | 64-KiB event units |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.

* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.

* Self-hosted target: PostgreSQL (PostgreSQL License, [https://www.postgresql.org/about/licence/](https://www.postgresql.org/about/licence/)). Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Compute Engine n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/compute/docs/general-purpose-machines](https://docs.cloud.google.com/compute/docs/general-purpose-machines)); a Persistent Disk volume holds up to 64 TiB ([https://docs.cloud.google.com/compute/docs/disks/persistent-disks](https://docs.cloud.google.com/compute/docs/disks/persistent-disks)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-1b3d195812060b0f8a3f49a7665e8f1d793b512b` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing).

## On Azure

### PostgreSQL Flexible Server

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Cross-account / cross-region buses | Bus | Out of scope | Full surface | Cross-account and cross-region bus routing is outside this mapping. |
| Event bus (default + custom) | Bus | Partial | Common | Terraform bus, rule and target declarations and EventBridge API calls use the same PostgreSQL records within the authenticated account. Custom buses are stored durably; the default bus is available per account. Bus tags are stored, by Terraform declaration and by CreateEventBus alike, but are not readable through the API: DescribeEventBus returns name and ARN as EventBridge does, and TagResource, UntagResource and ListTagsForResource are not served. Both doors refuse the same bus fields: CreateEventBus answers ValidationException for KmsKeyIdentifier, DeadLetterConfig, Description, EventSourceName and LogConfig, and a Terraform declaration that sets any of them fails the compile rather than applying without them: a customer-managed encryption key or a bus-level dead letter is not served here, and accepting the field would report a control that is not in force. Across the control plane, any request field an operation does not implement is refused by name rather than ignored; pagination keys are the exception, accepted and ignored because every list returns its whole set in one response. |
| Event bus SSE (customer KMS key) | Bus | Out of scope | Full surface | A customer-managed KMS key per bus is unsupported. Configure encryption on the backing store. |
| Schema registry / EventBridge Pipes | Ecosystem | Out of scope | Full surface | The schema registry and EventBridge Pipes are separate services outside this mapping. |
| PutEvents | Publish | Partial | Common | On an existing bus, each event and its matched rule-target delivery records commit in one transaction. Entries commit separately; a request failure can follow earlier commits, so retrying the batch can duplicate events. A nonexistent bus returns an event ID without storing or delivering the event, as EventBridge does. Confirm the bus exists before switching producers. Entries are validated as EventBridge validates them, and each refused entry is reported with EventBridge's error code while the rest of the batch is accepted. A bus can be named by ARN within the calling account and Region. PutEvents refuses EndpointId with ValidationException rather than dropping it: it names a global endpoint, so accepting it would report success for events that went to the local bus instead. TraceHeader is accepted and not propagated; there is no X-Ray here to correlate against. |
| Archive + replay | Replay | Out of scope | Full surface | Event archives and time-range replay are outside this mapping. |
| Rule: event pattern (JSON matcher) | Rules | Partial | Common | The adapter evaluates nested detail fields, \$or, prefix and suffix (including their case-insensitive forms), equals-ignore-case, wildcard with escaped asterisks, anything-but with values, prefix, suffix, wildcard and case-insensitive forms, numeric ranges, exists, and IPv4 and IPv6 cidr. 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. Check each operator used by the application. On every PutRule, pattern or scheduled, RoleArn and Tags are refused with ValidationException rather than dropped, and a Terraform rule declaring either fails the compile -- rule tags and a rule-level role are not stored -- and State accepts ENABLED and DISABLED only: ENABLED\_WITH\_ALL\_CLOUDTRAIL\_MANAGEMENT\_EVENTS is refused because this Cloud Adapter deployment has no CloudTrail management-event stream. |
| Rule: scheduled (cron / rate) | Rules | Partial | Most usage | Rates and six-field UTC cron produce durable delivery work. Cron supports values, lists, ranges including wrapping ranges, steps, names, ?, L, L-n, LW, nW, nL and n#k, with explicit years. L-n selects no day in a month too short for it. PutRule refuses the expressions EventBridge refuses, and also refuses a few forms EventBridge accepts but whose firing times are undocumented: a step of zero, # on a range or a day outside 1-7, W on a range, and L-n or ranged L in day-of-week. Schedules are allowed only on the default bus. Missed occurrences are not backfilled. This covers scheduled rules, not the separate EventBridge Scheduler service. |
| DLQ + retry policy on targets | Targets | Partial | Most usage | Retries use each target's attempt and event-age limits; age starts at acceptance. Delivery is at least once. Terminal dispatch failures can record durable work for an SQS dead-letter queue, whose sends retry separately and can also produce duplicates. The queue receives the rendered target payload with EventBridge's ERROR\_CODE, ERROR\_MESSAGE, RULE\_ARN and TARGET\_ARN attributes, plus RETRY\_ATTEMPTS and EXHAUSTED\_RETRY\_CONDITION when a retry or age limit was reached. ERROR\_CODE uses EventBridge's value for a destination 5xx, a permission refusal and a missing queue; every other failure, including timeouts and throttling, is reported as UNKNOWN. Exhausted dead-letter sends need operator attention; a configured queue does not guarantee that every failure reaches it. Lambda synchronous fallback uses this policy instead of Lambda asynchronous failure destinations. |
| Target input (constant / input\_path / transformer) | Targets | Partial | Full surface | Targets receive the event envelope, constant Input, an InputPath selection or an InputTransformer result. JSON paths support the root, dotted members and nonnegative array indices. Wildcards, filters, slices, recursive descent and quoted members are refused. Template variables must be declared; AWS reserved-variable coverage differs. As in EventBridge, an InputPath that selects nothing delivers \{}, and a transformer variable whose path selects nothing renders as an empty value. |
| Targets (fan a rule to N targets) | Targets | Partial | Common | Each matched rule-target pair has independent delivery work, including rules sharing a destination. SQS, SNS and Lambda require configured endpoints and permission to call the destination. PutTargets refuses a target of a supported type that this Cloud Adapter deployment has no delivery endpoint configured for, naming the type, the types it does deliver to and the endpoint setting to add; nothing is stored. Terraform apply does not yet apply that check -- a target declared that way is stored and its deliveries then fail and dead-letter -- so confirm with your operator that an endpoint is configured for each type you declare; the Cloud Adapter deployment startup log names each type it has none for. HTTP targets receive an unsigned POST; EventBridge Connections and API Destinations are outside this mapping. Lambda receivers that refuse asynchronous invocation use synchronous fallback, with function failures handled by the EventBridge retry policy. PutTargets refuses RoleArn, EcsParameters, SqsParameters, HttpParameters, KinesisParameters, BatchParameters, RedshiftDataParameters, SageMakerPipelineParameters, AppSyncParameters and RunCommandParameters with ValidationException; the whole request fails without storing its targets. A target ARN naming any other destination service -- Step Functions, Kinesis, ECS and the rest of the EventBridge target catalogue -- is refused the same way, by PutTargets and by Terraform apply alike, naming the destination and the supported types. AWS accepts those targets, so this is a deliberate difference: the alternative is accepting a target that no worker can ever deliver to. |

#### 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.

A restore is run by your administrator from the Cloud Adapter deployment's Terraform runbook: it creates a new server from the backups at the chosen point and moves the Cloud Adapter deployment to it by an apply, keeping the old server until the writes made after that point are reconciled. A restore returns the store to a chosen point within the last seven days: events accepted after that point are lost although PutEvents returned success, deliveries pending at that point may be sent again, and buses, rules and targets created after it return when their stacks are applied again.

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.

New installations use Microsoft Entra authentication with managed identities and disable password authentication. The runtime uses short-lived Entra access tokens over TLS; its connection string names the database and identity without including a password. The connection string is written to a Kubernetes Secret in the Cloud Adapter deployment cluster, where the adapter reads it, for the cluster-hosted runtime. Cloud Adapter deployment setup also publishes a password-free connection string for the adapters' separate identity in Azure Key Vault. The standalone Kubernetes installer delivers its runtime connection string through its Kubernetes Secret; it does not require that Cloud Adapter deployment-vault copy. In standalone installations the messaging runtime currently has the family server's Entra administrator role. Older Cloud Adapter deployments created before the Entra-only setup can retain their original password credentials. 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

The Tensor9 adapter provides the EventBridge API, and PostgreSQL stores your buses, rules, targets, accepted events and the deliveries still to be made. Terraform declarations and authenticated API calls work on the same records within an account. Point the application's EventBridge client at the adapter's endpoint, with the target environment's credentials.

For each event sent to an existing bus, the adapter evaluates the bus's enabled rules and saves the event together with one pending delivery per matched rule and target, so two rules with the same destination produce two deliveries. Each entry in a batch is saved on its own: a batch request can fail after earlier entries were saved, so retrying the whole batch can duplicate events. Delivery to destinations happens afterward.

An event sent to a bus that does not exist can still receive an event ID, but it is neither stored nor delivered. Confirm the bus exists before switching producers; an event ID alone does not mean the event was saved.

Event patterns support 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. Matching runs in the adapter, so rules can inspect nested detail fields directly. Case-insensitive matching folds Unicode letters as EventBridge does. A malformed pattern is rejected with EventBridge's reason; a pattern that is not valid JSON gets a different message.

#### Destination calls and payloads

Delivery workers pick up pending deliveries and call each target. SQS, SNS and Lambda calls are signed AWS requests, so each destination needs a reachable endpoint and permission for its operation: `SendMessage`, `Publish` or `InvokeFunction`. Permission to deliver to SQS does not imply SNS or Lambda access. HTTP targets receive an unsigned POST; EventBridge Connections and API destinations are not part of this mapping.

By default a target receives the EventBridge envelope: id, source, detail-type, time, region, account, resources and detail. A target can instead use a constant `Input`, an `InputPath` selection or an `InputTransformer` template, but only one of them. JSON paths support the root, dotted members and non-negative array indexes; other path syntax is rejected when you configure the target. Template variables must be declared, and not every AWS reserved variable is available. As in EventBridge, an `InputPath` that selects nothing delivers an empty JSON object, and a template variable that selects nothing renders as an empty value.

Lambda targets are invoked asynchronously first. If the function rejects asynchronous invocation, the worker falls back to a synchronous call; function errors then follow the target's EventBridge retry policy, and Lambda's asynchronous failure destinations do not apply. Deliveries in one batch are sent concurrently, so a slow function does not hold up the others in its batch, but the slowest send, up to a per-send time limit, delays the next batch.

#### Retries, duplicates and dead letters

Pending deliveries survive a restart. Deliveries a stopped worker had picked up resume when its lease expires, which can take up to about five minutes. A worker can retry after a lease expires even if the destination accepted the earlier call but the worker stopped before recording success. Delivery is therefore at least once, with no ordering guarantee; use an event key in your application to make repeated deliveries harmless.

Each target can set its retry count and maximum event age. Age is measured from when the adapter accepted the event, not from the event's own time field. The default number of attempts differs from AWS. One target's retries do not depend on another target's success.

When a delivery fails for good and the target has an SQS dead-letter queue, the failure and the pending dead-letter send are saved together in one database transaction. A separate worker then sends the target's rendered payload to that queue with EventBridge's `ERROR_CODE`, `ERROR_MESSAGE`, `RULE_ARN` and `TARGET_ARN` message attributes, plus `RETRY_ATTEMPTS` and `EXHAUSTED_RETRY_CONDITION` when a retry or age limit ran out. `ERROR_CODE` holds EventBridge's value for a destination 5xx error, a permission error and a missing queue; other failures, including timeouts and throttling, are reported as `UNKNOWN`. Dead-letter messages arrive asynchronously and can be duplicated after a crash. Sends to the dead-letter queue are retried separately, and a send that exhausts those retries needs operator attention, so a dead-letter queue does not guarantee that every failed event arrives there.

#### Scheduled rules

Scheduled rules create the same saved deliveries as matched events. Rate expressions and six-field UTC cron are supported, including values, ranges that wrap, lists, steps, names, the `?` 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 rejects a few forms EventBridge accepts but 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 for the database's calendar is accepted but never fires. Occurrences missed during downtime are not run later, and re-enabling a rule does not replay the time it was disabled. The separate EventBridge Scheduler service is not part of this mapping.

#### Limitations

* **Per-target `RoleArn` and service-specific parameters are not supported.** `PutTargets` rejects them, including FIFO `SqsParameters`, ECS and HTTP parameters, and a request with any unsupported target field fails as a whole. Check the operation table before migrating those declarations. - **Target updates behave differently: pending deliveries follow the new configuration.** Workers read a target's configuration when they pick up a delivery, so updating a target can redirect pending work; a delivery already picked up may still use the old configuration. - **Disabling a rule behaves differently: saved deliveries still go out.** It stops new matching but does not cancel accepted work. Drain pending deliveries before deleting and re-creating a target with the same name. - **Archives, replay, cross-account and cross-region routing, per-bus customer KMS keys, Pipes and the schema registry are not supported.** The saved delivery records are not an event archive your application can read. - **Unrecognized credentials behave differently: they get HTTP 403.** EventBridge answers 400.

#### Other considerations

**Who runs what.** Tensor9 operates the adapter, matcher, delivery workers and scheduler. Database availability, backups and capacity depend on the PostgreSQL deployment you choose. Set up database access and destination permissions with the deployment.

**Before switching producers.** Create buses, rules and targets first. AWS event history and pending deliveries are not copied, so keep the old destinations available until their pending work finishes. Check the payloads your targets receive, not only successful `PutEvents` responses.

**What to monitor.** Track pending deliveries, retries, permanent failures and failed dead-letter sends separately; a successful publish does not mean the event was delivered.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### EventBridge · Custom event units

Feature: EventBridge.

Estimated monthly service charges by Custom event units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/b2800df3a323fd0c40db5d735b9dae1109edd3c21b3c0d3ea967d0db75f6c45f-light.svg)

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/c77681d4be7c92545d999edfb69d8f9de0fc1b1c64dce220be2f08a034ed8e2d-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Custom event units (per second) | EventBridge | Target scenario | PostgreSQL Flexible Server | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL Flexible Server (one copy) | 141.44 | 141.44 |
| 0 | 0.00 | PostgreSQL Flexible Server (two copies) | 282.88 | 282.88 |
| 1 | 2.63 | PostgreSQL Flexible Server (one copy) | 141.44 | 138.81 |
| 1 | 2.63 | PostgreSQL Flexible Server (two copies) | 282.88 | 280.25 |
| 10 | 26.28 | PostgreSQL Flexible Server (one copy) | 141.44 | 115.16 |
| 10 | 26.28 | PostgreSQL Flexible Server (two copies) | 282.88 | 256.60 |
| 100 | 262.80 | PostgreSQL Flexible Server (one copy) | 141.44 | -121.36 |
| 100 | 262.80 | PostgreSQL Flexible Server (two copies) | 282.88 | 20.08 |
| 1,000 | 2,628.00 | PostgreSQL Flexible Server (one copy) | 1,051.02 | -1,576.98 |
| 1,000 | 2,628.00 | PostgreSQL Flexible Server (two copies) | 2,102.04 | -525.96 |
| 10,000 | 26,280.00 | PostgreSQL Flexible Server (one copy) | 6,248.62 | -20,031.38 |
| 10,000 | 26,280.00 | PostgreSQL Flexible Server (two copies) | 12,497.24 | -13,782.76 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 384 GiB memory and 100 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| PostgreSQL Flexible Server (one copy) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| PostgreSQL Flexible Server (one copy) | Representative event size | 1,024 | bytes |
| PostgreSQL Flexible Server (one copy) | Rules evaluated per event | 10 | rules |
| PostgreSQL Flexible Server (one copy) | Point-read work equivalent per rule | 0.1 | operations |
| PostgreSQL Flexible Server (one copy) | Matched targets per event | 1 | targets |
| PostgreSQL Flexible Server (one copy) | Delivery attempts | 1 | attempts/target |
| PostgreSQL Flexible Server (one copy) | Outbox residence window | 60 | seconds |
| PostgreSQL Flexible Server (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL Flexible Server (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL Flexible Server (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL Flexible Server (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL Flexible Server (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL Flexible Server (one copy) | Target list price · network GiB | 0.087 | USD/network GiB |
| PostgreSQL Flexible Server (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL Flexible Server (one copy) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour |
| PostgreSQL Flexible Server (one copy) | Target list price · GiB-hour | 0.009 | USD/GiB-hour |
| PostgreSQL Flexible Server (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL Flexible Server (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL Flexible Server (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL Flexible Server (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL Flexible Server (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL Flexible Server (one copy) | Target service minimum | 16.09 | USD/month |
| PostgreSQL Flexible Server (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL Flexible Server (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL Flexible Server (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL Flexible Server (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL Flexible Server (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL Flexible Server (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL Flexible Server (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL Flexible Server (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL Flexible Server (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL Flexible Server (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL Flexible Server (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL Flexible Server (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL Flexible Server (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL Flexible Server (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL Flexible Server (two copies) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| PostgreSQL Flexible Server (two copies) | Representative event size | 1,024 | bytes |
| PostgreSQL Flexible Server (two copies) | Rules evaluated per event | 10 | rules |
| PostgreSQL Flexible Server (two copies) | Point-read work equivalent per rule | 0.1 | operations |
| PostgreSQL Flexible Server (two copies) | Matched targets per event | 1 | targets |
| PostgreSQL Flexible Server (two copies) | Delivery attempts | 1 | attempts/target |
| PostgreSQL Flexible Server (two copies) | Outbox residence window | 60 | seconds |
| PostgreSQL Flexible Server (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL Flexible Server (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL Flexible Server (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL Flexible Server (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL Flexible Server (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL Flexible Server (two copies) | Target list price · network GiB | 0.087 | USD/network GiB |
| PostgreSQL Flexible Server (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL Flexible Server (two copies) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour |
| PostgreSQL Flexible Server (two copies) | Target list price · GiB-hour | 0.009 | USD/GiB-hour |
| PostgreSQL Flexible Server (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL Flexible Server (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL Flexible Server (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL Flexible Server (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL Flexible Server (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL Flexible Server (two copies) | Target service minimum | 16.09 | USD/month |
| PostgreSQL Flexible Server (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL Flexible Server (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL Flexible Server (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL Flexible Server (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL Flexible Server (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL Flexible Server (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL Flexible Server (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL Flexible Server (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL Flexible Server (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL Flexible Server (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL Flexible Server (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL Flexible Server (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL Flexible Server (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL Flexible Server (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Rules evaluated, matched targets and retries remain explicit. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → eastus, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.
* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.
* Azure Database for PostgreSQL Flexible Server bills vCores with a fixed memory ratio per series; the vCPU and memory rates decompose the General Purpose and Memory Optimized v5 prices. High availability bills the standby's compute and storage as a second copy. The minimum is the smallest Burstable server, which does not support high availability; the smallest General Purpose server (2 vCores) costs USD 133.62 per month. Additional IOPS, backup storage and reserved capacity are not selected.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: E96ds\_v5 has 96 vCores and 672 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute)); Premium SSD storage holds up to 32,767 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-storage](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-storage)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AWSEvents offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json)
* Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](https://prices.azure.com/api/retail/prices)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-b861f9005b6aff9fc3cfc370aadd088e6a0c9776` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

**EventBridge → PostgreSQL Flexible Server: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: eastus. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Custom event ingestion | 0.00 |
| Target: Provisioned primary CPU | 77.38 |
| Target: Provisioned primary RAM | 52.56 |
| Target: Provisioned primary disk | 11.50 |
| Target: Selected billable network | 0.00 |
| Target: Independent provisioned resources | 0.00 |
| Target: Independent managed resources | 0.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **141.44** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Representative event size | 1,024 | bytes |
| Rules evaluated per event | 10 | rules |
| Point-read work equivalent per rule | 0.1 | operations |
| Matched targets per event | 1 | targets |
| Delivery attempts | 1 | attempts/target |
| Outbox residence window | 60 | seconds |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.115 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0.087 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target list price · vCPU-hour | 0.053 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.009 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Target service minimum | 16.09 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Custom event ingestion | 0 | 64-KiB event units |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.

* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.

* Azure Database for PostgreSQL Flexible Server bills vCores with a fixed memory ratio per series; the vCPU and memory rates decompose the General Purpose and Memory Optimized v5 prices. High availability bills the standby's compute and storage as a second copy. The minimum is the smallest Burstable server, which does not support high availability; the smallest General Purpose server (2 vCores) costs USD 133.62 per month. Additional IOPS, backup storage and reserved capacity are not selected.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: E96ds\_v5 has 96 vCores and 672 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute)); Premium SSD storage holds up to 32,767 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-storage](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-storage)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-b861f9005b6aff9fc3cfc370aadd088e6a0c9776` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

### Azure Event Grid

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Cross-account / cross-region buses | Bus | Out of scope | Full surface | Cross-account and cross-region bus routing is outside this mapping. |
| Event bus (default + custom) | Bus | Out of scope | Common | A native topic is the storage counterpart of a bus. EventBridge delivery through Azure Event Grid is outside this profile's offered contract. Use the PostgreSQL service adapter for the EventBridge runtime. |
| Event bus SSE (customer KMS key) | Bus | Out of scope | Full surface | A customer-managed KMS key per bus is unsupported. Configure encryption on the backing store. |
| Schema registry / EventBridge Pipes | Ecosystem | Out of scope | Full surface | The schema registry and EventBridge Pipes are separate services outside this mapping. |
| PutEvents | Publish | Out of scope | Common | Native publication does not expose the EventBridge PutEvents contract. EventBridge delivery through Azure Event Grid is outside this profile's offered contract. Use the PostgreSQL service adapter for the EventBridge runtime. |
| Archive + replay | Replay | Out of scope | Full surface | Event archives and time-range replay are outside this mapping. |
| Rule: event pattern (JSON matcher) | Rules | Out of scope | Common | Event Grid advanced filters cover numeric and string conditions on supported fields, with their own syntax and limits. They do not cover the complete EventBridge pattern language. |
| Rule: scheduled (cron / rate) | Rules | Out of scope | Most usage | Scheduled rules require a separate scheduler and destination delivery mechanism; they are outside this mapping. |
| DLQ + retry policy on targets | Targets | Out of scope | Most usage | Event Grid topic subscriptions have native retry and event-age policies and can dead-letter to Blob Storage. That does not implement an EventBridge target's SQS dead-letter contract. |
| Target input (constant / input\_path / transformer) | Targets | Out of scope | Full surface | EventBridge Input, InputPath and InputTransformer behavior is outside this mapping. |
| Targets (fan a rule to N targets) | Targets | Out of scope | Common | Native broker delivery does not establish EventBridge target authorization, payload or retry semantics. EventBridge delivery through Azure Event Grid is outside this profile's offered contract. Use the PostgreSQL service adapter for the EventBridge runtime. |

#### What this comparison covers

EventBridge delivery through Azure Event Grid is outside this profile's offered contract. For EventBridge buses, rules and durable delivery to targets, use the PostgreSQL service adapter. This page compares how Event Grid itself works with EventBridge.

#### Topics, filters and handlers

An Event Grid topic can deliver events as CloudEvents. Event subscriptions apply advanced filters and deliver matching events to handlers. Advanced filters support numeric and string conditions on supported fields, with syntax and limits that differ from EventBridge, so a matching field name does not mean the pattern behaves the same.

Mapping EventBridge onto Event Grid would also need an adapter for the EventBridge API, and handlers that keep target payload selection, destination permissions and delivery results. Event Grid accepting an event does not mean it reached SQS, SNS or Lambda.

#### Limitations

Where Event Grid and EventBridge differ

* **Retries and dead letters behave differently.** Event Grid subscriptions use their own retry and event-age policies, and dead letters go to Blob Storage rather than an SQS dead-letter queue. See [Event Grid delivery and retry](https://learn.microsoft.com/en-us/azure/event-grid/delivery-and-retry).
* **Scheduled rules are not supported.** They need a separate scheduler and a way to deliver to the destination. Container Apps job schedules alone do not provide EventBridge's behaviour.
* **Target transformations, archives, replay, Pipes and the schema registry are not supported.** None of them has a counterpart in this mapping.

#### Other considerations

Microsoft operates Event Grid topic storage and delivery. Your handlers still need authentication, network access and processing that tolerates duplicates. Review those separately from Event Grid's retry policy when you evaluate a move.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

**Native or deployment mapping.** 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. Cost estimates describe the selected service resources; operation coverage remains separate.

##### EventBridge · Custom event units

Feature: EventBridge.

Estimated monthly service charges by Custom event units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: East US; currency: USD.

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/a28740f839b6c9af54280b50c889248fdb84999d81ad5c96f8c67d35fd299d2f-light.svg)

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/72a83cab0ece4401d10e5fadf09e9e534fd8cfcec8c06a9487c0c174104a80cd-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Custom event units (per second) | EventBridge | Target scenario | Azure Event Grid | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Azure Event Grid (one staging copy) | 118.18 | 118.18 |
| 0 | 0.00 | Azure Event Grid (two staging copies) | 236.36 | 236.36 |
| 1 | 2.63 | Azure Event Grid (one staging copy) | 121.27 | 118.64 |
| 1 | 2.63 | Azure Event Grid (two staging copies) | 239.45 | 236.82 |
| 10 | 26.28 | Azure Event Grid (one staging copy) | 149.65 | 123.37 |
| 10 | 26.28 | Azure Event Grid (two staging copies) | 267.83 | 241.55 |
| 100 | 262.80 | Azure Event Grid (one staging copy) | 433.48 | 170.68 |
| 100 | 262.80 | Azure Event Grid (two staging copies) | 551.66 | 288.86 |
| 1,000 | 2,628.00 | Azure Event Grid (one staging copy) | 3,979.96 | 1,351.96 |
| 1,000 | 2,628.00 | Azure Event Grid (two staging copies) | 4,806.39 | 2,178.39 |
| 10,000 | 26,280.00 | Azure Event Grid (one staging copy) | 36,409.48 | 10,129.48 |
| 10,000 | 26,280.00 | Azure Event Grid (two staging copies) | 41,283.03 | 15,003.03 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 384 GiB memory and 100 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Azure Event Grid (one staging copy) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Azure Event Grid (one staging copy) | Representative event size | 1,024 | bytes |
| Azure Event Grid (one staging copy) | Rules evaluated per event | 10 | rules |
| Azure Event Grid (one staging copy) | Point-read work equivalent per rule | 0.1 | operations |
| Azure Event Grid (one staging copy) | Matched targets per event | 1 | targets |
| Azure Event Grid (one staging copy) | Delivery attempts | 1 | attempts/target |
| Azure Event Grid (one staging copy) | Outbox residence window | 60 | seconds |
| Azure Event Grid (one staging copy) | Target price guess · read | 0 | USD/read |
| Azure Event Grid (one staging copy) | Target price guess · write | 0 | USD/write |
| Azure Event Grid (one staging copy) | Target list price · provider operation | 0.0000006 | USD/provider operation |
| Azure Event Grid (one staging copy) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Azure Event Grid (one staging copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Azure Event Grid (one staging copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Azure Event Grid (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Azure Event Grid (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Azure Event Grid (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Azure Event Grid (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Azure Event Grid (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Azure Event Grid (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Azure Event Grid (one staging copy) | Target price guess · input token | 0 | USD/input token |
| Azure Event Grid (one staging copy) | Target price guess · output token | 0 | USD/output token |
| Azure Event Grid (one staging copy) | Included before billing · provider operation | 100,000 | provider operation |
| Azure Event Grid (one staging copy) | Target monthly base charge | 0 | USD/month |
| Azure Event Grid (one staging copy) | Approximate target service minimum | 0 | USD/month |
| Azure Event Grid (one staging copy) | Minimum primary CPU | 2 | vCPU |
| Azure Event Grid (one staging copy) | Minimum primary RAM | 8 | GiB |
| Azure Event Grid (one staging copy) | Minimum primary disk | 100 | GiB |
| Azure Event Grid (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Azure Event Grid (one staging copy) | Allocated share of provisioned cost | 1 | fraction |
| Azure Event Grid (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Azure Event Grid (one staging copy) | Planning peak / mean work | 2 | multiplier |
| Azure Event Grid (one staging copy) | Planning primary CPU utilization | 0.7 | fraction |
| Azure Event Grid (one staging copy) | Resident state reserved in RAM | 0.1 | fraction |
| Azure Event Grid (one staging copy) | Planning disk utilization | 0.8 | fraction |
| Azure Event Grid (one staging copy) | Maintenance and log disk reserve | 20 | GiB |
| Azure Event Grid (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Azure Event Grid (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Azure Event Grid (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Azure Event Grid (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Azure Event Grid (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Azure Event Grid (two staging copies) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Azure Event Grid (two staging copies) | Representative event size | 1,024 | bytes |
| Azure Event Grid (two staging copies) | Rules evaluated per event | 10 | rules |
| Azure Event Grid (two staging copies) | Point-read work equivalent per rule | 0.1 | operations |
| Azure Event Grid (two staging copies) | Matched targets per event | 1 | targets |
| Azure Event Grid (two staging copies) | Delivery attempts | 1 | attempts/target |
| Azure Event Grid (two staging copies) | Outbox residence window | 60 | seconds |
| Azure Event Grid (two staging copies) | Target price guess · read | 0 | USD/read |
| Azure Event Grid (two staging copies) | Target price guess · write | 0 | USD/write |
| Azure Event Grid (two staging copies) | Target list price · provider operation | 0.0000006 | USD/provider operation |
| Azure Event Grid (two staging copies) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Azure Event Grid (two staging copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Azure Event Grid (two staging copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Azure Event Grid (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Azure Event Grid (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Azure Event Grid (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Azure Event Grid (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Azure Event Grid (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Azure Event Grid (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Azure Event Grid (two staging copies) | Target price guess · input token | 0 | USD/input token |
| Azure Event Grid (two staging copies) | Target price guess · output token | 0 | USD/output token |
| Azure Event Grid (two staging copies) | Included before billing · provider operation | 100,000 | provider operation |
| Azure Event Grid (two staging copies) | Target monthly base charge | 0 | USD/month |
| Azure Event Grid (two staging copies) | Approximate target service minimum | 0 | USD/month |
| Azure Event Grid (two staging copies) | Minimum primary CPU | 2 | vCPU |
| Azure Event Grid (two staging copies) | Minimum primary RAM | 8 | GiB |
| Azure Event Grid (two staging copies) | Minimum primary disk | 100 | GiB |
| Azure Event Grid (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Azure Event Grid (two staging copies) | Allocated share of provisioned cost | 1 | fraction |
| Azure Event Grid (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Azure Event Grid (two staging copies) | Planning peak / mean work | 2 | multiplier |
| Azure Event Grid (two staging copies) | Planning primary CPU utilization | 0.7 | fraction |
| Azure Event Grid (two staging copies) | Resident state reserved in RAM | 0.1 | fraction |
| Azure Event Grid (two staging copies) | Planning disk utilization | 0.8 | fraction |
| Azure Event Grid (two staging copies) | Maintenance and log disk reserve | 20 | GiB |
| Azure Event Grid (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Azure Event Grid (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Azure Event Grid (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Azure Event Grid (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Azure Event Grid (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Rules evaluated, matched targets and retries remain explicit. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → East US, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Native/deployment comparison scope: 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.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.
* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.
* Azure Event Grid Basic (custom and system topics, domains) bills operations after 100,000 free a month: published events, advanced-filter matches and delivery attempts, each per 64 KB of payload. The family's managed operations approximate publications plus delivery work. Event Grid namespaces (Standard tier) instead bill USD 0.04 per throughput-unit hour plus event and MQTT operations.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AWSEvents offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json)
* Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](https://prices.azure.com/api/retail/prices)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-656ce2b6cd8a54740cc930f862ce2db533e713fa` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

**EventBridge → Azure Event Grid: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: East US. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Custom event ingestion | 0.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Published bytes | 0.00 |
| Target: Delivered bytes | 0.00 |
| Target: Target native provider operations after 100000 included | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Durable staging CPU | 60.30 |
| Target: Durable staging RAM | 40.88 |
| Target: Durable staging disk | 17.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **118.18** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Representative event size | 1,024 | bytes |
| Rules evaluated per event | 10 | rules |
| Point-read work equivalent per rule | 0.1 | operations |
| Matched targets per event | 1 | targets |
| Delivery attempts | 1 | attempts/target |
| Outbox residence window | 60 | seconds |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target list price · provider operation | 0.0000006 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Included before billing · provider operation | 100,000 | provider operation |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Custom event ingestion | 0 | 64-KiB event units |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Native/deployment comparison scope: 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.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.

* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.

* Azure Event Grid Basic (custom and system topics, domains) bills operations after 100,000 free a month: published events, advanced-filter matches and delivery attempts, each per 64 KB of payload. The family's managed operations approximate publications plus delivery work. Event Grid namespaces (Standard tier) instead bill USD 0.04 per throughput-unit hour plus event and MQTT operations.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-656ce2b6cd8a54740cc930f862ce2db533e713fa` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

### Container Apps

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Event bus + PutEvents | Bus | Out of scope | Common | This infrastructure mapping provides no event bus or EventBridge request endpoint. |
| Archive + replay / Pipes / schema registry / cross-account | Ecosystem | Out of scope | Full surface | These EventBridge capabilities are outside this schedule-only mapping. |
| Rule: event pattern (JSON matcher) | Rules | Out of scope | Common | Deployment refuses event-pattern rules. Use the PostgreSQL adapter for supported event patterns. |
| Rule: scheduled (cron / rate) | Rules | Partial | Common | Infrastructure translation creates a scheduled Container Apps Job for representable cron and rate expressions. The job uses five-field UTC cron; deployment rejects expressions it cannot represent. This covers the schedule configuration, not delivery to an EventBridge target. |
| DLQ + retry policy on targets | Targets | Out of scope | Most usage | EventBridge target retry and dead-letter delivery are outside this mapping. Job retries and queue redrive are separate policies. |
| Target input (constant / input\_path / transformer) | Targets | Out of scope | Full surface | Deployment refuses target input overrides, input paths and transformers. |
| Target: SNS / Lambda / non-SQS | Targets | Out of scope | Full surface | Deployment refuses non-SQS target declarations. |
| Target: SQS | Targets | Out of scope | Common | Scheduled target delivery is outside this mapping. A configured job schedule does not send an event to SQS. Use the PostgreSQL adapter for scheduled EventBridge delivery. |

#### How it works

Tensor9 turns each supported EventBridge scheduled rule into an Azure Container Apps Job with the same schedule. That is all this mapping does. There is no EventBridge API endpoint and no event bus, and the job does not deliver the scheduled event to the rule's target.

If your application needs EventBridge pattern matching, `PutEvents` and delivery to targets, use the PostgreSQL service adapter instead. A job schedule alone does not send the scheduled event to SQS.

#### Cron and rate schedules

Container Apps scheduled jobs use five-field cron in UTC. Tensor9 translates AWS six-field cron and `rate` expressions that can be written that way, and rejects expressions it cannot keep. Review the generated schedule and allow for job start-up time; a scheduled trigger does not guarantee immediate processing.

See [Container Apps jobs](https://learn.microsoft.com/en-us/azure/container-apps/jobs) for how Azure schedules and runs jobs.

#### Limitations

Where Container Apps Jobs and EventBridge differ

* **Event-pattern rules are not supported.** Deployment rejects a rule with an `event_pattern`; only scheduled rules translate.
* **Targets other than SQS are not supported, and SQS targets receive nothing.** Deployment rejects non-SQS targets. An SQS target is accepted, but accepting it does not deliver the scheduled event to the queue.
* **Target input overrides are not supported.** Constant input, input paths and input transformers are rejected.
* **EventBridge retries and dead-letter queues are not supported.** Container Apps job retries and SQS queue redrive are separate policies you configure.
* **Archives, replay, Pipes, the schema registry and cross-account buses are not supported.** None of them has a counterpart in this mapping.

#### Other considerations

Microsoft runs the jobs. Estimate compute use from schedule frequency, run time and allocated resources. Any processing your application needs requires its own executable, destination credentials and network access; the schedule translation does not provide them.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

**Native or deployment mapping.** 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. Cost estimates describe the selected service resources; operation coverage remains separate.

##### EventBridge · Custom event units

Feature: EventBridge.

Estimated monthly service charges by Custom event units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: East US; currency: USD.

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/42c2367f04440420adee09b5df241694ddb129d6fda7c687295c221b6ac500e4-light.svg)

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/9b73590726b75726f4fa074f97cb11fe7aa83672a77e573b1ac6372df06ff05f-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Custom event units (per second) | EventBridge | Target scenario | Container Apps | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Container Apps (one staging copy) | 118.18 | 118.18 |
| 0 | 0.00 | Container Apps (two staging copies) | 236.36 | 236.36 |
| 1 | 2.63 | Container Apps (one staging copy) | 119.48 | 116.85 |
| 1 | 2.63 | Container Apps (two staging copies) | 237.66 | 235.03 |
| 10 | 26.28 | Container Apps (one staging copy) | 138.40 | 112.12 |
| 10 | 26.28 | Container Apps (two staging copies) | 256.58 | 230.30 |
| 100 | 262.80 | Container Apps (one staging copy) | 327.62 | 64.82 |
| 100 | 262.80 | Container Apps (two staging copies) | 445.80 | 183.00 |
| 1,000 | 2,628.00 | Container Apps (one staging copy) | 2,928.02 | 300.02 |
| 1,000 | 2,628.00 | Container Apps (two staging copies) | 3,754.45 | 1,126.45 |
| 10,000 | 26,280.00 | Container Apps (one staging copy) | 25,896.74 | -383.26 |
| 10,000 | 26,280.00 | Container Apps (two staging copies) | 30,770.29 | 4,490.29 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 384 GiB memory and 100 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Container Apps (one staging copy) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Container Apps (one staging copy) | Representative event size | 1,024 | bytes |
| Container Apps (one staging copy) | Rules evaluated per event | 10 | rules |
| Container Apps (one staging copy) | Point-read work equivalent per rule | 0.1 | operations |
| Container Apps (one staging copy) | Matched targets per event | 1 | targets |
| Container Apps (one staging copy) | Delivery attempts | 1 | attempts/target |
| Container Apps (one staging copy) | Outbox residence window | 60 | seconds |
| Container Apps (one staging copy) | Target price guess · read | 0 | USD/read |
| Container Apps (one staging copy) | Target price guess · write | 0 | USD/write |
| Container Apps (one staging copy) | Target list price · provider operation | 0.0000004 | USD/provider operation |
| Container Apps (one staging copy) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Container Apps (one staging copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Container Apps (one staging copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Container Apps (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Container Apps (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Container Apps (one staging copy) | Target list price · vCPU-hour | 0.0864 | USD/vCPU-hour |
| Container Apps (one staging copy) | Target list price · GiB-hour | 0.0108 | USD/GiB-hour |
| Container Apps (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Container Apps (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Container Apps (one staging copy) | Target price guess · input token | 0 | USD/input token |
| Container Apps (one staging copy) | Target price guess · output token | 0 | USD/output token |
| Container Apps (one staging copy) | Included before billing · vCPU-hour | 50 | vCPU-hour |
| Container Apps (one staging copy) | Included before billing · GiB-hour | 100 | GiB-hour |
| Container Apps (one staging copy) | Included before billing · provider operation | 2,000,000 | provider operation |
| Container Apps (one staging copy) | Target monthly base charge | 0 | USD/month |
| Container Apps (one staging copy) | Approximate target service minimum | 0 | USD/month |
| Container Apps (one staging copy) | Minimum primary CPU | 2 | vCPU |
| Container Apps (one staging copy) | Minimum primary RAM | 8 | GiB |
| Container Apps (one staging copy) | Minimum primary disk | 100 | GiB |
| Container Apps (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Container Apps (one staging copy) | Allocated share of provisioned cost | 1 | fraction |
| Container Apps (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Container Apps (one staging copy) | Planning peak / mean work | 2 | multiplier |
| Container Apps (one staging copy) | Planning primary CPU utilization | 0.7 | fraction |
| Container Apps (one staging copy) | Resident state reserved in RAM | 0.1 | fraction |
| Container Apps (one staging copy) | Planning disk utilization | 0.8 | fraction |
| Container Apps (one staging copy) | Maintenance and log disk reserve | 20 | GiB |
| Container Apps (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Container Apps (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Container Apps (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Container Apps (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Container Apps (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Container Apps (two staging copies) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Container Apps (two staging copies) | Representative event size | 1,024 | bytes |
| Container Apps (two staging copies) | Rules evaluated per event | 10 | rules |
| Container Apps (two staging copies) | Point-read work equivalent per rule | 0.1 | operations |
| Container Apps (two staging copies) | Matched targets per event | 1 | targets |
| Container Apps (two staging copies) | Delivery attempts | 1 | attempts/target |
| Container Apps (two staging copies) | Outbox residence window | 60 | seconds |
| Container Apps (two staging copies) | Target price guess · read | 0 | USD/read |
| Container Apps (two staging copies) | Target price guess · write | 0 | USD/write |
| Container Apps (two staging copies) | Target list price · provider operation | 0.0000004 | USD/provider operation |
| Container Apps (two staging copies) | Target price guess · GiB-month | 0 | USD/GiB-month |
| Container Apps (two staging copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Container Apps (two staging copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Container Apps (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Container Apps (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Container Apps (two staging copies) | Target list price · vCPU-hour | 0.0864 | USD/vCPU-hour |
| Container Apps (two staging copies) | Target list price · GiB-hour | 0.0108 | USD/GiB-hour |
| Container Apps (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Container Apps (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Container Apps (two staging copies) | Target price guess · input token | 0 | USD/input token |
| Container Apps (two staging copies) | Target price guess · output token | 0 | USD/output token |
| Container Apps (two staging copies) | Included before billing · vCPU-hour | 50 | vCPU-hour |
| Container Apps (two staging copies) | Included before billing · GiB-hour | 100 | GiB-hour |
| Container Apps (two staging copies) | Included before billing · provider operation | 2,000,000 | provider operation |
| Container Apps (two staging copies) | Target monthly base charge | 0 | USD/month |
| Container Apps (two staging copies) | Approximate target service minimum | 0 | USD/month |
| Container Apps (two staging copies) | Minimum primary CPU | 2 | vCPU |
| Container Apps (two staging copies) | Minimum primary RAM | 8 | GiB |
| Container Apps (two staging copies) | Minimum primary disk | 100 | GiB |
| Container Apps (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Container Apps (two staging copies) | Allocated share of provisioned cost | 1 | fraction |
| Container Apps (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Container Apps (two staging copies) | Planning peak / mean work | 2 | multiplier |
| Container Apps (two staging copies) | Planning primary CPU utilization | 0.7 | fraction |
| Container Apps (two staging copies) | Resident state reserved in RAM | 0.1 | fraction |
| Container Apps (two staging copies) | Planning disk utilization | 0.8 | fraction |
| Container Apps (two staging copies) | Maintenance and log disk reserve | 20 | GiB |
| Container Apps (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Container Apps (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Container Apps (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Container Apps (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Container Apps (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Rules evaluated, matched targets and retries remain explicit. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → East US, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Native/deployment comparison scope: 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.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.
* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.
* Azure Container Apps (Consumption plan) bills active vCPU-seconds, GiB-seconds and requests after a monthly free grant per subscription. Idle minimum replicas bill USD 0.000003 per vCPU-second and are not inferred; TCP apps bill per connection.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AWSEvents offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json)
* Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](https://prices.azure.com/api/retail/prices)
* Azure Container Apps pricing: [https://azure.microsoft.com/en-us/pricing/details/container-apps/](https://azure.microsoft.com/en-us/pricing/details/container-apps/)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-31f645677d120d117c82ffa4430248237b09c947` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices), [Azure Container Apps pricing](https://azure.microsoft.com/en-us/pricing/details/container-apps/).

**EventBridge → Container Apps: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: East US. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Custom event ingestion | 0.00 |
| Target: Target native provider operations after 2000000 included | 0.00 |
| Target: Execution or worker CPU after 50 included | 0.00 |
| Target: Execution or worker RAM after 100 included | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Durable staging CPU | 60.30 |
| Target: Durable staging RAM | 40.88 |
| Target: Durable staging disk | 17.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **118.18** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Representative event size | 1,024 | bytes |
| Rules evaluated per event | 10 | rules |
| Point-read work equivalent per rule | 0.1 | operations |
| Matched targets per event | 1 | targets |
| Delivery attempts | 1 | attempts/target |
| Outbox residence window | 60 | seconds |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target list price · provider operation | 0.0000004 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target list price · vCPU-hour | 0.0864 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.0108 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Included before billing · vCPU-hour | 50 | vCPU-hour |
| Included before billing · GiB-hour | 100 | GiB-hour |
| Included before billing · provider operation | 2,000,000 | provider operation |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Custom event ingestion | 0 | 64-KiB event units |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Native/deployment comparison scope: 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.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.

* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.

* Azure Container Apps (Consumption plan) bills active vCPU-seconds, GiB-seconds and requests after a monthly free grant per subscription. Idle minimum replicas bill USD 0.000003 per vCPU-second and are not inferred; TCP apps bill per connection.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-31f645677d120d117c82ffa4430248237b09c947` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices), [Azure Container Apps pricing](https://azure.microsoft.com/en-us/pricing/details/container-apps/).

## On Google Cloud

### Cloud SQL for PostgreSQL

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Cross-account / cross-region buses | Bus | Out of scope | Full surface | Cross-account and cross-region bus routing is outside this mapping. |
| Event bus (default + custom) | Bus | Partial | Common | Terraform bus, rule and target declarations and EventBridge API calls use the same PostgreSQL records within the authenticated account. Custom buses are stored durably; the default bus is available per account. Bus tags are stored, by Terraform declaration and by CreateEventBus alike, but are not readable through the API: DescribeEventBus returns name and ARN as EventBridge does, and TagResource, UntagResource and ListTagsForResource are not served. Both doors refuse the same bus fields: CreateEventBus answers ValidationException for KmsKeyIdentifier, DeadLetterConfig, Description, EventSourceName and LogConfig, and a Terraform declaration that sets any of them fails the compile rather than applying without them: a customer-managed encryption key or a bus-level dead letter is not served here, and accepting the field would report a control that is not in force. Across the control plane, any request field an operation does not implement is refused by name rather than ignored; pagination keys are the exception, accepted and ignored because every list returns its whole set in one response. |
| Event bus SSE (customer KMS key) | Bus | Out of scope | Full surface | A customer-managed KMS key per bus is unsupported. Configure encryption on the backing store. |
| Schema registry / EventBridge Pipes | Ecosystem | Out of scope | Full surface | The schema registry and EventBridge Pipes are separate services outside this mapping. |
| PutEvents | Publish | Partial | Common | On an existing bus, each event and its matched rule-target delivery records commit in one transaction. Entries commit separately; a request failure can follow earlier commits, so retrying the batch can duplicate events. A nonexistent bus returns an event ID without storing or delivering the event, as EventBridge does. Confirm the bus exists before switching producers. Entries are validated as EventBridge validates them, and each refused entry is reported with EventBridge's error code while the rest of the batch is accepted. A bus can be named by ARN within the calling account and Region. PutEvents refuses EndpointId with ValidationException rather than dropping it: it names a global endpoint, so accepting it would report success for events that went to the local bus instead. TraceHeader is accepted and not propagated; there is no X-Ray here to correlate against. |
| Archive + replay | Replay | Out of scope | Full surface | Event archives and time-range replay are outside this mapping. |
| Rule: event pattern (JSON matcher) | Rules | Partial | Common | The adapter evaluates nested detail fields, \$or, prefix and suffix (including their case-insensitive forms), equals-ignore-case, wildcard with escaped asterisks, anything-but with values, prefix, suffix, wildcard and case-insensitive forms, numeric ranges, exists, and IPv4 and IPv6 cidr. 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. Check each operator used by the application. On every PutRule, pattern or scheduled, RoleArn and Tags are refused with ValidationException rather than dropped, and a Terraform rule declaring either fails the compile -- rule tags and a rule-level role are not stored -- and State accepts ENABLED and DISABLED only: ENABLED\_WITH\_ALL\_CLOUDTRAIL\_MANAGEMENT\_EVENTS is refused because this Cloud Adapter deployment has no CloudTrail management-event stream. |
| Rule: scheduled (cron / rate) | Rules | Partial | Most usage | Rates and six-field UTC cron produce durable delivery work. Cron supports values, lists, ranges including wrapping ranges, steps, names, ?, L, L-n, LW, nW, nL and n#k, with explicit years. L-n selects no day in a month too short for it. PutRule refuses the expressions EventBridge refuses, and also refuses a few forms EventBridge accepts but whose firing times are undocumented: a step of zero, # on a range or a day outside 1-7, W on a range, and L-n or ranged L in day-of-week. Schedules are allowed only on the default bus. Missed occurrences are not backfilled. This covers scheduled rules, not the separate EventBridge Scheduler service. |
| DLQ + retry policy on targets | Targets | Partial | Most usage | Retries use each target's attempt and event-age limits; age starts at acceptance. Delivery is at least once. Terminal dispatch failures can record durable work for an SQS dead-letter queue, whose sends retry separately and can also produce duplicates. The queue receives the rendered target payload with EventBridge's ERROR\_CODE, ERROR\_MESSAGE, RULE\_ARN and TARGET\_ARN attributes, plus RETRY\_ATTEMPTS and EXHAUSTED\_RETRY\_CONDITION when a retry or age limit was reached. ERROR\_CODE uses EventBridge's value for a destination 5xx, a permission refusal and a missing queue; every other failure, including timeouts and throttling, is reported as UNKNOWN. Exhausted dead-letter sends need operator attention; a configured queue does not guarantee that every failure reaches it. Lambda synchronous fallback uses this policy instead of Lambda asynchronous failure destinations. |
| Target input (constant / input\_path / transformer) | Targets | Partial | Full surface | Targets receive the event envelope, constant Input, an InputPath selection or an InputTransformer result. JSON paths support the root, dotted members and nonnegative array indices. Wildcards, filters, slices, recursive descent and quoted members are refused. Template variables must be declared; AWS reserved-variable coverage differs. As in EventBridge, an InputPath that selects nothing delivers \{}, and a transformer variable whose path selects nothing renders as an empty value. |
| Targets (fan a rule to N targets) | Targets | Partial | Common | Each matched rule-target pair has independent delivery work, including rules sharing a destination. SQS, SNS and Lambda require configured endpoints and permission to call the destination. PutTargets refuses a target of a supported type that this Cloud Adapter deployment has no delivery endpoint configured for, naming the type, the types it does deliver to and the endpoint setting to add; nothing is stored. Terraform apply does not yet apply that check -- a target declared that way is stored and its deliveries then fail and dead-letter -- so confirm with your operator that an endpoint is configured for each type you declare; the Cloud Adapter deployment startup log names each type it has none for. HTTP targets receive an unsigned POST; EventBridge Connections and API Destinations are outside this mapping. Lambda receivers that refuse asynchronous invocation use synchronous fallback, with function failures handled by the EventBridge retry policy. PutTargets refuses RoleArn, EcsParameters, SqsParameters, HttpParameters, KinesisParameters, BatchParameters, RedshiftDataParameters, SageMakerPipelineParameters, AppSyncParameters and RunCommandParameters with ValidationException; the whole request fails without storing its targets. A target ARN naming any other destination service -- Step Functions, Kinesis, ECS and the rest of the EventBridge target catalogue -- is refused the same way, by PutTargets and by Terraform apply alike, naming the destination and the supported types. AWS accepts those targets, so this is a deliberate difference: the alternative is accepting a target that no worker can ever deliver to. |

#### 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.

A restore is run by your administrator from the Cloud Adapter deployment's Terraform runbook: it creates a new instance from the backups at the chosen point and moves the Cloud Adapter deployment to it by an apply, keeping the old instance until the writes made after that point are reconciled. A restore returns the store to a chosen point within the last seven days: events accepted after that point are lost although PutEvents returned success, deliveries pending at that point may be sent again, and buses, rules and targets created after it return when their stacks are applied again.

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, dedicated 1-vCPU, 6-GiB default machine size. The adapter runs as one pod, replaced rather than overlapped on each update; connections, storage and throughput are shared limits, so watch them alongside pending delivery work.

New GCP setups use Cloud SQL IAM service-account logins, IAM tokens and password-free connection strings. The Cloud Adapter deployment runtime reads its connection strings from Kubernetes Secrets. A legacy Cloud Adapter deployment's off-cluster adapters read their own IAM connection strings from Secret Manager; the standalone installer instead delivers each service's own login and database connection string through a Kubernetes Secret. A privileged Cloud Adapter deployment administrator or initialization job applies the database grants. Existing installations may retain older credentials; this setup does not migrate them. The application never handles these connection strings. 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

The Tensor9 adapter provides the EventBridge API, and PostgreSQL stores your buses, rules, targets, accepted events and the deliveries still to be made. Terraform declarations and authenticated API calls work on the same records within an account. Point the application's EventBridge client at the adapter's endpoint, with the target environment's credentials.

For each event sent to an existing bus, the adapter evaluates the bus's enabled rules and saves the event together with one pending delivery per matched rule and target, so two rules with the same destination produce two deliveries. Each entry in a batch is saved on its own: a batch request can fail after earlier entries were saved, so retrying the whole batch can duplicate events. Delivery to destinations happens afterward.

An event sent to a bus that does not exist can still receive an event ID, but it is neither stored nor delivered. Confirm the bus exists before switching producers; an event ID alone does not mean the event was saved.

Event patterns support 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. Matching runs in the adapter, so rules can inspect nested detail fields directly. Case-insensitive matching folds Unicode letters as EventBridge does. A malformed pattern is rejected with EventBridge's reason; a pattern that is not valid JSON gets a different message.

#### Destination calls and payloads

Delivery workers pick up pending deliveries and call each target. SQS, SNS and Lambda calls are signed AWS requests, so each destination needs a reachable endpoint and permission for its operation: `SendMessage`, `Publish` or `InvokeFunction`. Permission to deliver to SQS does not imply SNS or Lambda access. HTTP targets receive an unsigned POST; EventBridge Connections and API destinations are not part of this mapping.

By default a target receives the EventBridge envelope: id, source, detail-type, time, region, account, resources and detail. A target can instead use a constant `Input`, an `InputPath` selection or an `InputTransformer` template, but only one of them. JSON paths support the root, dotted members and non-negative array indexes; other path syntax is rejected when you configure the target. Template variables must be declared, and not every AWS reserved variable is available. As in EventBridge, an `InputPath` that selects nothing delivers an empty JSON object, and a template variable that selects nothing renders as an empty value.

Lambda targets are invoked asynchronously first. If the function rejects asynchronous invocation, the worker falls back to a synchronous call; function errors then follow the target's EventBridge retry policy, and Lambda's asynchronous failure destinations do not apply. Deliveries in one batch are sent concurrently, so a slow function does not hold up the others in its batch, but the slowest send, up to a per-send time limit, delays the next batch.

#### Retries, duplicates and dead letters

Pending deliveries survive a restart. Deliveries a stopped worker had picked up resume when its lease expires, which can take up to about five minutes. A worker can retry after a lease expires even if the destination accepted the earlier call but the worker stopped before recording success. Delivery is therefore at least once, with no ordering guarantee; use an event key in your application to make repeated deliveries harmless.

Each target can set its retry count and maximum event age. Age is measured from when the adapter accepted the event, not from the event's own time field. The default number of attempts differs from AWS. One target's retries do not depend on another target's success.

When a delivery fails for good and the target has an SQS dead-letter queue, the failure and the pending dead-letter send are saved together in one database transaction. A separate worker then sends the target's rendered payload to that queue with EventBridge's `ERROR_CODE`, `ERROR_MESSAGE`, `RULE_ARN` and `TARGET_ARN` message attributes, plus `RETRY_ATTEMPTS` and `EXHAUSTED_RETRY_CONDITION` when a retry or age limit ran out. `ERROR_CODE` holds EventBridge's value for a destination 5xx error, a permission error and a missing queue; other failures, including timeouts and throttling, are reported as `UNKNOWN`. Dead-letter messages arrive asynchronously and can be duplicated after a crash. Sends to the dead-letter queue are retried separately, and a send that exhausts those retries needs operator attention, so a dead-letter queue does not guarantee that every failed event arrives there.

#### Scheduled rules

Scheduled rules create the same saved deliveries as matched events. Rate expressions and six-field UTC cron are supported, including values, ranges that wrap, lists, steps, names, the `?` 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 rejects a few forms EventBridge accepts but 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 for the database's calendar is accepted but never fires. Occurrences missed during downtime are not run later, and re-enabling a rule does not replay the time it was disabled. The separate EventBridge Scheduler service is not part of this mapping.

#### Limitations

* **Per-target `RoleArn` and service-specific parameters are not supported.** `PutTargets` rejects them, including FIFO `SqsParameters`, ECS and HTTP parameters, and a request with any unsupported target field fails as a whole. Check the operation table before migrating those declarations. - **Target updates behave differently: pending deliveries follow the new configuration.** Workers read a target's configuration when they pick up a delivery, so updating a target can redirect pending work; a delivery already picked up may still use the old configuration. - **Disabling a rule behaves differently: saved deliveries still go out.** It stops new matching but does not cancel accepted work. Drain pending deliveries before deleting and re-creating a target with the same name. - **Archives, replay, cross-account and cross-region routing, per-bus customer KMS keys, Pipes and the schema registry are not supported.** The saved delivery records are not an event archive your application can read. - **Unrecognized credentials behave differently: they get HTTP 403.** EventBridge answers 400.

#### Other considerations

**Who runs what.** Tensor9 operates the adapter, matcher, delivery workers and scheduler. Database availability, backups and capacity depend on the PostgreSQL deployment you choose. Set up database access and destination permissions with the deployment.

**Before switching producers.** Create buses, rules and targets first. AWS event history and pending deliveries are not copied, so keep the old destinations available until their pending work finishes. Check the payloads your targets receive, not only successful `PutEvents` responses.

**What to monitor.** Track pending deliveries, retries, permanent failures and failed dead-letter sends separately; a successful publish does not mean the event was delivered.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### EventBridge · Custom event units

Feature: EventBridge.

Estimated monthly service charges by Custom event units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/dc5aa9d30d6823fb397e9129db514d7796fa47dc1de701c0bf95c4c5ee9c4f03-light.svg)

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/8aa174def4a87c0b25cf9ff57026a892fd60a021b778e7218464072388b24721-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Custom event units (per second) | EventBridge | Target scenario | Cloud SQL for PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 118.18 |
| 0 | 0.00 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 236.36 |
| 1 | 2.63 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 115.55 |
| 1 | 2.63 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 233.73 |
| 10 | 26.28 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 91.90 |
| 10 | 26.28 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 210.08 |
| 100 | 262.80 | Cloud SQL for PostgreSQL (one copy) | 118.18 | -144.62 |
| 100 | 262.80 | Cloud SQL for PostgreSQL (two copies) | 236.36 | -26.44 |
| 1,000 | 2,628.00 | Cloud SQL for PostgreSQL (one copy) | 826.42 | -1,801.58 |
| 1,000 | 2,628.00 | Cloud SQL for PostgreSQL (two copies) | 1,652.85 | -975.15 |
| 10,000 | 26,280.00 | Cloud SQL for PostgreSQL (one copy) | 4,873.54 | -21,406.46 |
| 10,000 | 26,280.00 | Cloud SQL for PostgreSQL (two copies) | 9,747.09 | -16,532.91 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 384 GiB memory and 100 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Cloud SQL for PostgreSQL (one copy) | Representative event size | 1,024 | bytes |
| Cloud SQL for PostgreSQL (one copy) | Rules evaluated per event | 10 | rules |
| Cloud SQL for PostgreSQL (one copy) | Point-read work equivalent per rule | 0.1 | operations |
| Cloud SQL for PostgreSQL (one copy) | Matched targets per event | 1 | targets |
| Cloud SQL for PostgreSQL (one copy) | Delivery attempts | 1 | attempts/target |
| Cloud SQL for PostgreSQL (one copy) | Outbox residence window | 60 | seconds |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Cloud SQL for PostgreSQL (one copy) | Target list price · GiB-month | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud SQL for PostgreSQL (one copy) | Target list price · network GiB | 0.19 | USD/network GiB |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (one copy) | Target list price · GiB-hour | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| Cloud SQL for PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| Cloud SQL for PostgreSQL (one copy) | Target service minimum | 9.365 | USD/month |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Cloud SQL for PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud SQL for PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Cloud SQL for PostgreSQL (two copies) | Representative event size | 1,024 | bytes |
| Cloud SQL for PostgreSQL (two copies) | Rules evaluated per event | 10 | rules |
| Cloud SQL for PostgreSQL (two copies) | Point-read work equivalent per rule | 0.1 | operations |
| Cloud SQL for PostgreSQL (two copies) | Matched targets per event | 1 | targets |
| Cloud SQL for PostgreSQL (two copies) | Delivery attempts | 1 | attempts/target |
| Cloud SQL for PostgreSQL (two copies) | Outbox residence window | 60 | seconds |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Cloud SQL for PostgreSQL (two copies) | Target list price · GiB-month | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud SQL for PostgreSQL (two copies) | Target list price · network GiB | 0.19 | USD/network GiB |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (two copies) | Target list price · GiB-hour | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| Cloud SQL for PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| Cloud SQL for PostgreSQL (two copies) | Target service minimum | 9.365 | USD/month |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Cloud SQL for PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud SQL for PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Rules evaluated, matched targets and retries remain explicit. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.
* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.
* Cloud SQL Enterprise edition (PostgreSQL) publishes separate vCPU, memory and SSD prices for zonal instances; a high-availability (regional) instance bills exactly twice each, which the standby copy reproduces. Enterprise Plus, committed-use discounts, backups (USD 0.08 per GiB-month) and idle IPv4 addresses (0.01 per hour) are not selected.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AWSEvents offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json)
* Cloud SQL pricing: [https://cloud.google.com/sql/pricing](https://cloud.google.com/sql/pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-c010cda26af1a7ba1dd7b53dd4a4725b1efe0c50` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Cloud SQL pricing](https://cloud.google.com/sql/pricing).

**EventBridge → Cloud SQL for PostgreSQL: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Custom event ingestion | 0.00 |
| Target: Provisioned primary CPU | 60.30 |
| Target: Provisioned primary RAM | 40.88 |
| Target: Provisioned primary disk | 17.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent provisioned resources | 0.00 |
| Target: Independent managed resources | 0.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **118.18** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Representative event size | 1,024 | bytes |
| Rules evaluated per event | 10 | rules |
| Point-read work equivalent per rule | 0.1 | operations |
| Matched targets per event | 1 | targets |
| Delivery attempts | 1 | attempts/target |
| Outbox residence window | 60 | seconds |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.17 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0.19 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.007 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Target service minimum | 9.365 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Custom event ingestion | 0 | 64-KiB event units |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.

* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.

* Cloud SQL Enterprise edition (PostgreSQL) publishes separate vCPU, memory and SSD prices for zonal instances; a high-availability (regional) instance bills exactly twice each, which the standby copy reproduces. Enterprise Plus, committed-use discounts, backups (USD 0.08 per GiB-month) and idle IPv4 addresses (0.01 per hour) are not selected.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-c010cda26af1a7ba1dd7b53dd4a4725b1efe0c50` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Cloud SQL pricing](https://cloud.google.com/sql/pricing).

### Pub/Sub

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| Cross-account / cross-region buses | Bus | Out of scope | Full surface | Cross-account and cross-region bus routing is outside this mapping. |
| Event bus (default + custom) | Bus | Out of scope | Common | A native topic is the storage counterpart of a bus. EventBridge delivery through Google Cloud Pub/Sub is outside this profile's offered contract. Use the PostgreSQL service adapter for the EventBridge runtime. |
| Event bus SSE (customer KMS key) | Bus | Out of scope | Full surface | A customer-managed KMS key per bus is unsupported. Configure encryption on the backing store. |
| Schema registry / EventBridge Pipes | Ecosystem | Out of scope | Full surface | The schema registry and EventBridge Pipes are separate services outside this mapping. |
| PutEvents | Publish | Out of scope | Common | Native publication does not expose the EventBridge PutEvents contract. EventBridge delivery through Google Cloud Pub/Sub is outside this profile's offered contract. Use the PostgreSQL service adapter for the EventBridge runtime. |
| Archive + replay | Replay | Out of scope | Full surface | Event archives and time-range replay are outside this mapping. |
| Rule: event pattern (JSON matcher) | Rules | Out of scope | Common | Pub/Sub filters message attributes, not the message body. Promoting source and detail-type to attributes can cover simple rules; nested EventBridge detail matching needs additional processing. |
| Rule: scheduled (cron / rate) | Rules | Out of scope | Most usage | Scheduled rules require a separate scheduler and destination delivery mechanism; they are outside this mapping. |
| DLQ + retry policy on targets | Targets | Out of scope | Most usage | Pub/Sub subscription redelivery and dead-letter topics have different semantics from EventBridge target retries and an SQS dead-letter queue. They do not establish destination success or EventBridge event-age limits. |
| Target input (constant / input\_path / transformer) | Targets | Out of scope | Full surface | EventBridge Input, InputPath and InputTransformer behavior is outside this mapping. |
| Targets (fan a rule to N targets) | Targets | Out of scope | Common | Native broker delivery does not establish EventBridge target authorization, payload or retry semantics. EventBridge delivery through Google Cloud Pub/Sub is outside this profile's offered contract. Use the PostgreSQL service adapter for the EventBridge runtime. |

#### Scope

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 features and the differences that matter when you evaluate 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. Copying source and detail-type into attributes can express simple conditions; matching on nested EventBridge detail needs extra processing. See [Pub/Sub message filtering](https://cloud.google.com/pubsub/docs/subscription-message-filter).

An EventBridge mapping would also need an adapter to accept `PutEvents` and manage rules, plus workers that apply each target's input selection and call authorized destinations. Pub/Sub acknowledging a message is not the same as that destination call completing.

#### Limitations

* **EventBridge per-target retries, event-age limits and SQS dead-letter queues are not supported.** Pub/Sub's subscription redelivery and dead-letter topics are different mechanisms. - **Scheduled rules are not supported.** A separate scheduler, such as Cloud Scheduler, would have to reproduce rule timing and destination behavior. - **Archives, replay, Pipes and the schema registry are not supported.**

#### Other considerations

Google operates Pub/Sub storage and subscription redelivery. Your consumers still need authentication, network access and processing that tolerates duplicates. Pub/Sub's broker features alone do not provide EventBridge API compatibility or target delivery.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

**Native or deployment mapping.** 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. Cost estimates describe the selected service resources; operation coverage remains separate.

##### EventBridge · Custom event units

Feature: EventBridge.

Estimated monthly service charges by Custom event units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/16c7dba4070cb0c5a88273dbd90cdc09eed69d63d10a7ac09b78f0f1a734a78f-light.svg)

![EventBridge · Custom event units: monthly service charges by Custom event units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/53f12b3ec4714477de57d46de9d6180ce82ea11e4d13cc29e9aad6ad45a4ceb4-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Custom event units (per second) | EventBridge | Target scenario | Pub/Sub | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Pub/Sub (one staging copy) | 118.18 | 118.18 |
| 0 | 0.00 | Pub/Sub (two staging copies) | 236.36 | 236.36 |
| 1 | 2.63 | Pub/Sub (one staging copy) | 118.37 | 115.75 |
| 1 | 2.63 | Pub/Sub (two staging copies) | 236.55 | 233.92 |
| 10 | 26.28 | Pub/Sub (one staging copy) | 120.14 | 93.86 |
| 10 | 26.28 | Pub/Sub (two staging copies) | 238.31 | 212.03 |
| 100 | 262.80 | Pub/Sub (one staging copy) | 137.76 | -125.04 |
| 100 | 262.80 | Pub/Sub (two staging copies) | 255.94 | -6.86 |
| 1,000 | 2,628.00 | Pub/Sub (one staging copy) | 1,022.26 | -1,605.74 |
| 1,000 | 2,628.00 | Pub/Sub (two staging copies) | 1,848.68 | -779.32 |
| 10,000 | 26,280.00 | Pub/Sub (one staging copy) | 6,831.87 | -19,448.13 |
| 10,000 | 26,280.00 | Pub/Sub (two staging copies) | 11,705.41 | -14,574.59 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 96 vCPU, 384 GiB memory and 100 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Pub/Sub (one staging copy) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Pub/Sub (one staging copy) | Representative event size | 1,024 | bytes |
| Pub/Sub (one staging copy) | Rules evaluated per event | 10 | rules |
| Pub/Sub (one staging copy) | Point-read work equivalent per rule | 0.1 | operations |
| Pub/Sub (one staging copy) | Matched targets per event | 1 | targets |
| Pub/Sub (one staging copy) | Delivery attempts | 1 | attempts/target |
| Pub/Sub (one staging copy) | Outbox residence window | 60 | seconds |
| Pub/Sub (one staging copy) | Target price guess · read | 0 | USD/read |
| Pub/Sub (one staging copy) | Target price guess · write | 0 | USD/write |
| Pub/Sub (one staging copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Pub/Sub (one staging copy) | Target list price · GiB-month | 0.27 | USD/GiB-month |
| Pub/Sub (one staging copy) | Target list price · published GiB | 0.0390625 | USD/published GiB |
| Pub/Sub (one staging copy) | Target list price · delivered GiB | 0.0390625 | USD/delivered GiB |
| Pub/Sub (one staging copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Pub/Sub (one staging copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Pub/Sub (one staging copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Pub/Sub (one staging copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Pub/Sub (one staging copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Pub/Sub (one staging copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Pub/Sub (one staging copy) | Target price guess · input token | 0 | USD/input token |
| Pub/Sub (one staging copy) | Target price guess · output token | 0 | USD/output token |
| Pub/Sub (one staging copy) | Target monthly base charge | 0 | USD/month |
| Pub/Sub (one staging copy) | Approximate target service minimum | 0 | USD/month |
| Pub/Sub (one staging copy) | Minimum primary CPU | 2 | vCPU |
| Pub/Sub (one staging copy) | Minimum primary RAM | 8 | GiB |
| Pub/Sub (one staging copy) | Minimum primary disk | 100 | GiB |
| Pub/Sub (one staging copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Pub/Sub (one staging copy) | Allocated share of provisioned cost | 1 | fraction |
| Pub/Sub (one staging copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Pub/Sub (one staging copy) | Planning peak / mean work | 2 | multiplier |
| Pub/Sub (one staging copy) | Planning primary CPU utilization | 0.7 | fraction |
| Pub/Sub (one staging copy) | Resident state reserved in RAM | 0.1 | fraction |
| Pub/Sub (one staging copy) | Planning disk utilization | 0.8 | fraction |
| Pub/Sub (one staging copy) | Maintenance and log disk reserve | 20 | GiB |
| Pub/Sub (one staging copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Pub/Sub (one staging copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Pub/Sub (one staging copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Pub/Sub (one staging copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Pub/Sub (one staging copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Pub/Sub (two staging copies) | Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Pub/Sub (two staging copies) | Representative event size | 1,024 | bytes |
| Pub/Sub (two staging copies) | Rules evaluated per event | 10 | rules |
| Pub/Sub (two staging copies) | Point-read work equivalent per rule | 0.1 | operations |
| Pub/Sub (two staging copies) | Matched targets per event | 1 | targets |
| Pub/Sub (two staging copies) | Delivery attempts | 1 | attempts/target |
| Pub/Sub (two staging copies) | Outbox residence window | 60 | seconds |
| Pub/Sub (two staging copies) | Target price guess · read | 0 | USD/read |
| Pub/Sub (two staging copies) | Target price guess · write | 0 | USD/write |
| Pub/Sub (two staging copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Pub/Sub (two staging copies) | Target list price · GiB-month | 0.27 | USD/GiB-month |
| Pub/Sub (two staging copies) | Target list price · published GiB | 0.0390625 | USD/published GiB |
| Pub/Sub (two staging copies) | Target list price · delivered GiB | 0.0390625 | USD/delivered GiB |
| Pub/Sub (two staging copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Pub/Sub (two staging copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Pub/Sub (two staging copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Pub/Sub (two staging copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Pub/Sub (two staging copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Pub/Sub (two staging copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Pub/Sub (two staging copies) | Target price guess · input token | 0 | USD/input token |
| Pub/Sub (two staging copies) | Target price guess · output token | 0 | USD/output token |
| Pub/Sub (two staging copies) | Target monthly base charge | 0 | USD/month |
| Pub/Sub (two staging copies) | Approximate target service minimum | 0 | USD/month |
| Pub/Sub (two staging copies) | Minimum primary CPU | 2 | vCPU |
| Pub/Sub (two staging copies) | Minimum primary RAM | 8 | GiB |
| Pub/Sub (two staging copies) | Minimum primary disk | 100 | GiB |
| Pub/Sub (two staging copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Pub/Sub (two staging copies) | Allocated share of provisioned cost | 1 | fraction |
| Pub/Sub (two staging copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Pub/Sub (two staging copies) | Planning peak / mean work | 2 | multiplier |
| Pub/Sub (two staging copies) | Planning primary CPU utilization | 0.7 | fraction |
| Pub/Sub (two staging copies) | Resident state reserved in RAM | 0.1 | fraction |
| Pub/Sub (two staging copies) | Planning disk utilization | 0.8 | fraction |
| Pub/Sub (two staging copies) | Maintenance and log disk reserve | 20 | GiB |
| Pub/Sub (two staging copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Pub/Sub (two staging copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Pub/Sub (two staging copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Pub/Sub (two staging copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Pub/Sub (two staging copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Rules evaluated, matched targets and retries remain explicit. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Native/deployment comparison scope: 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.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.
* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.
* Google Pub/Sub bills published and delivered bytes at the Message Delivery Basic rate and retained messages per GiB-month. Each request is billed at no less than 1,000 bytes; the family's batching and delivery assumptions must represent that. The first 10 GiB of combined throughput a month is free per billing account and is not applied. BigQuery and Cloud Storage subscriptions bill USD 50 per TiB instead. Unacknowledged messages younger than one day bill no storage.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AWSEvents offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json)
* Pub/Sub pricing: [https://cloud.google.com/pubsub/pricing](https://cloud.google.com/pubsub/pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-c03446d19e35e982d41ca3014545e9ec0d6edd9c` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Pub/Sub pricing](https://cloud.google.com/pubsub/pricing).

**EventBridge → Pub/Sub: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Custom event ingestion | 0.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target ingress events | 0.00 |
| Target: Published bytes | 0.00 |
| Target: Delivered bytes | 0.00 |
| Target: Target native provider operations | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Durable staging CPU | 60.30 |
| Target: Durable staging RAM | 40.88 |
| Target: Durable staging disk | 17.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **118.18** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Scheduler, Pipes, archive/replay and API destination prices; destination execution charges.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Custom event ingestion | 0.000001 | USD/64-KiB event units |
| Representative event size | 1,024 | bytes |
| Rules evaluated per event | 10 | rules |
| Point-read work equivalent per rule | 0.1 | operations |
| Matched targets per event | 1 | targets |
| Delivery attempts | 1 | attempts/target |
| Outbox residence window | 60 | seconds |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.27 | USD/GiB-month |
| Target list price · published GiB | 0.0390625 | USD/published GiB |
| Target list price · delivered GiB | 0.0390625 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Custom event ingestion | 0 | 64-KiB event units |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Native/deployment comparison scope: 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.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* The durable events table, in-process matcher and delivery outbox run even when a native broker is selected in a proposed architecture.

* Native Pub/Sub/Event Grid rows are designs; cost coverage does not make those runtime paths served.

* Google Pub/Sub bills published and delivered bytes at the Message Delivery Basic rate and retained messages per GiB-month. Each request is billed at no less than 1,000 bytes; the family's batching and delivery assumptions must represent that. The first 10 GiB of combined throughput a month is free per billing account and is not applied. BigQuery and Cloud Storage subscriptions bill USD 50 per TiB instead. Unacknowledged messages younger than one day bill no storage.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-c03446d19e35e982d41ca3014545e9ec0d6edd9c` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AWSEvents offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/us-east-1/index.json), [Pub/Sub pricing](https://cloud.google.com/pubsub/pricing).

## Costs

Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model's cost curve. Adapter hosting and Tensor9 fees are excluded. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method, what the estimates include and how to read their qualifications.

| Backend | Sampled workload | Price basis | Origin USD/month | Backend USD/month | Difference | Mapping |
| - | - | - | -: | -: | -: | - |
| Azure Event Grid | Custom event units: 100 per second; one staging copy | Cited list prices, 2026-10-22 | 262.80 | 433.48 | +170.68 | Native or deployment |
| Cloud SQL for PostgreSQL | Custom event units: 100 per second; one copy | Cited list prices, 2026-10-22 | 262.80 | 118.18 | -144.62 | Service adapter |
| Container Apps | Custom event units: 100 per second; one staging copy | Cited list prices, 2026-10-22 | 262.80 | 327.62 | +64.82 | Native or deployment |
| PostgreSQL | Custom event units: 100 per second; one copy | Cited list prices, 2026-10-22 | 262.80 | 80.90 | -181.90 | Service adapter |
| PostgreSQL Flexible Server | Custom event units: 100 per second; one copy | Cited list prices, 2026-10-22 | 262.80 | 141.44 | -121.36 | Service adapter |
| Pub/Sub | Custom event units: 100 per second; one staging copy | Cited list prices, 2026-10-22 | 262.80 | 137.76 | -125.04 | Native or deployment |

Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row's difference at its stated workload rather than charges across rows.
Cost curves across workload sizes, with every assumption and exclusion: [EventBridge costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/additional-services/aws-events).

## Service level agreements

> [!WARNING]
>
> These tables show Tensor9's standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.

Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider's own SLA. Each origin-to-target pair has its own terms or an explicit pending status.

See the [SLA tables](https://docs.tensor9.com/cloud-adapter-early-access/support/service-adapter-slas.md), [measurement rules](https://docs.tensor9.com/cloud-adapter-early-access/support/service-levels.md), and [scaling conditions](https://docs.tensor9.com/cloud-adapter-early-access/support/scaling-and-limits.md).

### 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

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Bounded event acceptance and matching adapter-added latency | +25 ms monthly p99 | `aws::1.0.0::events`: `PutEvents` | 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. |
| Bus, rule and target configuration adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::events`: `CreateEventBus`, `DeleteEventBus`, `DeleteRule`, `DescribeEventBus`, `DescribeRule`, `DisableRule`, `EnableRule`, `ListEventBuses`, `ListRules`, `ListTargetsByRule`, `PutRule`, `PutTargets`, `RemoveTargets` | 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. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::events`: `PutEvents`, `CreateEventBus`, `DeleteEventBus`, `DeleteRule`, `DescribeEventBus`, `DescribeRule`, `DisableRule`, `EnableRule`, `ListEventBuses`, `ListRules`, `ListTargetsByRule`, `PutRule`, `PutTargets`, `RemoveTargets` | 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. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

For `azure::1.0.0::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 (adapter-added).** `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 (adapter-added).** `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.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

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 bus `order-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

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Bounded event acceptance and matching adapter-added latency | +25 ms monthly p99 | `aws::1.0.0::events`: `PutEvents` | 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. |
| Bus, rule and target configuration adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::events`: `CreateEventBus`, `DeleteEventBus`, `DeleteRule`, `DescribeEventBus`, `DescribeRule`, `DisableRule`, `EnableRule`, `ListEventBuses`, `ListRules`, `ListTargetsByRule`, `PutRule`, `PutTargets`, `RemoveTargets` | 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. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::events`: `PutEvents`, `CreateEventBus`, `DeleteEventBus`, `DeleteRule`, `DescribeEventBus`, `DescribeRule`, `DisableRule`, `EnableRule`, `ListEventBuses`, `ListRules`, `ListTargetsByRule`, `PutRule`, `PutTargets`, `RemoveTargets` | 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. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

For `google::1.0.0::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 (adapter-added).** `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 (adapter-added).** `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.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

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 bus `order-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

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Bounded event acceptance and matching adapter-added latency | +25 ms monthly p99 | `aws::1.0.0::events`: `PutEvents` | 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. |
| Bus, rule and target configuration adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::events`: `CreateEventBus`, `DeleteEventBus`, `DeleteRule`, `DescribeEventBus`, `DescribeRule`, `DisableRule`, `EnableRule`, `ListEventBuses`, `ListRules`, `ListTargetsByRule`, `PutRule`, `PutTargets`, `RemoveTargets` | 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. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::events`: `PutEvents`, `CreateEventBus`, `DeleteEventBus`, `DeleteRule`, `DescribeEventBus`, `DescribeRule`, `DisableRule`, `EnableRule`, `ListEventBuses`, `ListRules`, `ListTargetsByRule`, `PutRule`, `PutTargets`, `RemoveTargets` | 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. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

For `postgres::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 (adapter-added).** `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 (adapter-added).** `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.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

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 bus `order-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. Set `T9_API_KEY` as described in [Install and Authenticate](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/install-and-authenticate.md), then list the adapters your account may use with this origin:

```sh theme={null}
tensor9 adapt svc list \
  -origin aws::1.0.0::events
```

The result is limited to directed mappings for this origin that your account is entitled to use. Use a returned backend identifier when configuring the adapter or investigating a request.

Request binary access from [hello@tensor9.com](mailto:hello@tensor9.com) if your account does not yet include this direction.

## Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

## Configure, tune and debug

Start with [setup](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/overview.md) and [configuration](https://docs.tensor9.com/cloud-adapter-early-access/configuration/overview.md). Use [tuning](https://docs.tensor9.com/cloud-adapter-early-access/tuning/overview.md) to understand supported request tags, [debugging](https://docs.tensor9.com/cloud-adapter-early-access/debugging/overview.md) to investigate a request, and [High Fidelity Cloud Emulators](https://docs.tensor9.com/cloud-adapter-early-access/local-testing/overview.md) to validate a bounded reproduction.

For requests that go through an entitled service adapter, use [tensor9 explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/explain.md) and [x-t9-explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/response-headers.md) to inspect the selected mapping.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.