EventBridge - Tensor9

Preview On this page

Coverage by target cloud
How the backends compare
- Max adaptation
- Infrastructure-only adaptation
On Google Cloud
- Via Cloud SQL for PostgreSQL
- Via Pub/Sub
On Google Cloud, Azure, OCI, and Private Kubernetes
- Via PostgreSQL
On Azure
Costs
Service level agreements
Debug this service

Coverage by target cloud

Target cloud	Available
Google Cloud	✓
Azure	✓
OCI	✓
Private Kubernetes	✓

How the backends compare

Each row compares a capability of EventBridge with its adaptation on each backend. A dash means this row is not stated for that backend.

Max adaptation

Capability	EventBridge	Google Cloud · Cloud SQL for PostgreSQL	Google Cloud, Azure, OCI, and Private Kubernetes · PostgreSQL	Azure · PostgreSQL Flexible Server
Event bus + PutEvents	native	EventBridge API with PostgreSQL persistence	EventBridge API with PostgreSQL persistence	EventBridge API with PostgreSQL persistence
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	Partial - Nested detail, $or and EventBridge content filters, checked against EventBridge’s own answers
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	Rates and six-field UTC cron, refusing a few forms with undocumented timing; no missed-occurrence backfill
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	Separate durable work per rule and target; authorized SQS, SNS, Lambda and unsigned HTTP delivery
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	Partial - Per-target retry and age limits; asynchronous SQS dead-letter handoff with separate retries and possible duplicates
Durability · backups + cluster rebuild	AWS-managed regional service	buses, rules, events and pending deliveries persist on the Google-operated instance outside the appliance cluster, with daily automated backups with point-in-time recovery over seven days of transaction logs; a cluster rebuild does not lose them	-	buses, rules, events and pending deliveries persist on the Microsoft-operated server outside the appliance cluster, with automated backups with a seven-day retention window and point-in-time restore inside it; a cluster rebuild does not lose them
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 appliance	dedicated service	one Cloud SQL instance per appliance 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 appliance serves on PostgreSQL, so their load shares the instance’s connection, storage and throughput limits	-	-
API coverage	full	high	high	high
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 appliance	dedicated service	-	-	one Flexible Server per appliance 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 appliance serves on PostgreSQL, so their load shares the server’s connection, storage and throughput limits

Infrastructure-only adaptation

Capability	EventBridge	Google Cloud · Pub/Sub	Azure · Azure Event Grid	Azure · Container Apps
Event bus + PutEvents	native	Outside the offered EventBridge contract	Outside the offered EventBridge contract	-
Event-pattern matching	Yes	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.	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.	-
Scheduled rules · cron / rate	native	Outside this mapping	Outside this mapping	-
Rule targets · fan-out	SQS / SNS / Lambda / …	Outside this mapping	Outside this mapping	-
Target DLQ + retry	Yes	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.	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.	-
API coverage	full	minimal	minimal	partial

On Google Cloud

Via 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 appliance 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 appliance 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 appliance 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 appliance provisions one instance with no public IP address, reached only through a Private Service Connect endpoint inside the appliance’s network, and every connection uses TLS. The PostgreSQL major version is fixed when the appliance 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 appliance’s Terraform runbook: it creates a new instance from the backups at the chosen point and moves the appliance 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 appliance use the same database when they run on PostgreSQL, and the appliance’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 appliance runtime reads its connection strings from Kubernetes Secrets. A legacy appliance’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 appliance 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 appliance 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

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.

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): 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). 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).
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
Cloud 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, Cloud 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): 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). 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).
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, Cloud SQL pricing.

Via 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. 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 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs 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.

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): 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). 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).
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
Pub/Sub 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, Pub/Sub 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

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): 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). 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).
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, Pub/Sub pricing.

On Google Cloud, Azure, OCI, and Private Kubernetes

Via 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 appliance 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 appliance 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 appliance 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

Destination calls and payloads

Retries, duplicates and dead letters

Scheduled rules

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

Example monthly charges

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.

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/). 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): 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). 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); a Persistent Disk volume holds up to 64 TiB (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
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

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, Compute Engine general-purpose machine pricing, Disk and image pricing, 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

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/). 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): 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). 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); a Persistent Disk volume holds up to 64 TiB (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, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

On Azure

Via 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 appliance 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 appliance 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 appliance 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 appliance provisions one server, injected into the appliance’s virtual network with no public endpoint, and every connection uses TLS. The PostgreSQL major version is fixed when the appliance 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 appliance’s Terraform runbook: it creates a new server from the backups at the chosen point and moves the appliance 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 appliance use the same database when they run on PostgreSQL, and the appliance’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 appliance cluster, where the adapter reads it, for the cluster-hosted runtime. Appliance 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 appliance-vault copy. In standalone installations the messaging runtime currently has the family server’s Entra administrator role. Older appliances created before the Entra-only setup can retain their original password credentials. Removing the appliance 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

Destination calls and payloads

Retries, duplicates and dead letters

Scheduled rules

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

Example monthly charges

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.

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): 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). 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); Premium SSD storage holds up to 32,767 GiB (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
Azure Retail Prices API: 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, Azure Retail Prices API. 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

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): 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). 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); Premium SSD storage holds up to 32,767 GiB (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, Azure Retail Prices API.

Via 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.
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 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs 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.

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): 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). 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).
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
Azure Retail Prices API: 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, Azure Retail Prices API. 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

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): 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). 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).
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, Azure Retail Prices API.

Via 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 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 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs 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.

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): 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). 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).
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
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/

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, Azure Retail Prices API, Azure Container Apps pricing. 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

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): 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). 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).
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, Azure Retail Prices API, Azure Container Apps 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 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.

Service level agreements

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, measurement rules, and scaling conditions.

EventBridge to Container Apps

SLA status: Not applicable Scheduled jobs run as Container Apps jobs. This mapping does not expose an event bus or a PutEvents adapter endpoint; job execution is not fabric request latency.

EventBridge to Azure Event Grid

SLA status: Not applicable This mapping uses native Event Grid delivery rather than an EventBridge API endpoint. Event delivery follows the target service’s behavior; there is no EventBridge adapter request to measure.

EventBridge to PostgreSQL Flexible Server

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.

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

What counts toward latency

Endpoint reachability and request failures

Scaling and target-service capacity

Data and behavior guarantees

Example and diagnosis

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.

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

What counts toward latency

Endpoint reachability and request failures

Scaling and target-service capacity

Data and behavior guarantees

Example and diagnosis

Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.

​Coverage by target cloud

​How the backends compare

​Max adaptation

​Infrastructure-only adaptation

​On Google Cloud

​Via Cloud SQL for PostgreSQL

​PostgreSQL hosting

​Accepting and matching events

​Destination calls and payloads

​Retries, duplicates and dead letters

​Scheduled rules

​Limitations

​Other considerations

​Example monthly charges

EventBridge · Custom event units

​Via Pub/Sub

​Scope

​Topics, filters and destination delivery

​Limitations

​Other considerations

​Example monthly charges

EventBridge · Custom event units

​On Google Cloud, Azure, OCI, and Private Kubernetes

​Via PostgreSQL

​Accepting and matching events

​Destination calls and payloads

​Retries, duplicates and dead letters

​Scheduled rules

​Limitations

​Other considerations

​Example monthly charges

EventBridge · Custom event units

​On Azure

​Via PostgreSQL Flexible Server

​PostgreSQL hosting

​Accepting and matching events

​Destination calls and payloads

​Retries, duplicates and dead letters

​Scheduled rules

​Limitations

​Other considerations

​Example monthly charges

EventBridge · Custom event units

​Via Azure Event Grid

​What this comparison covers

​Topics, filters and handlers

​Limitations

​Other considerations

​Example monthly charges

EventBridge · Custom event units

​Via Container Apps

​How it works

​Cron and rate schedules

​Limitations

​Other considerations

​Example monthly charges

EventBridge · Custom event units

​Costs

​Service level agreements

​EventBridge to Container Apps

​EventBridge to Azure Event Grid

​EventBridge to PostgreSQL Flexible Server

​What this adapter does

​How the latency targets were chosen

​What counts toward latency

​Endpoint reachability and request failures

​Scaling and target-service capacity

​Data and behavior guarantees

​Example and diagnosis

​EventBridge to Cloud SQL for PostgreSQL

​What this adapter does

​How the latency targets were chosen

​What counts toward latency

​Endpoint reachability and request failures

​Scaling and target-service capacity

​Data and behavior guarantees

​Example and diagnosis

​EventBridge to Pub/Sub

​EventBridge to PostgreSQL

​What this adapter does

Coverage by target cloud

How the backends compare

Max adaptation

Infrastructure-only adaptation

On Google Cloud

Via Cloud SQL for PostgreSQL

PostgreSQL hosting

Accepting and matching events

Destination calls and payloads

Retries, duplicates and dead letters

Scheduled rules

Limitations

Other considerations

Example monthly charges

Via Pub/Sub

Scope

Topics, filters and destination delivery

Limitations

Other considerations

Example monthly charges

On Google Cloud, Azure, OCI, and Private Kubernetes

Via PostgreSQL

Accepting and matching events

Destination calls and payloads

Retries, duplicates and dead letters

Scheduled rules

Limitations

Other considerations

Example monthly charges

On Azure

Via PostgreSQL Flexible Server

PostgreSQL hosting

Accepting and matching events

Destination calls and payloads

Retries, duplicates and dead letters

Scheduled rules

Limitations

Other considerations

Example monthly charges

Via Azure Event Grid

What this comparison covers

Topics, filters and handlers

Limitations

Other considerations

Example monthly charges

Via Container Apps

How it works

Cron and rate schedules

Limitations

Other considerations

Example monthly charges

Costs

Service level agreements

EventBridge to Container Apps

EventBridge to Azure Event Grid

EventBridge to PostgreSQL Flexible Server

What this adapter does

How the latency targets were chosen

What counts toward latency

Endpoint reachability and request failures

Scaling and target-service capacity

Data and behavior guarantees

Example and diagnosis

EventBridge to Cloud SQL for PostgreSQL

What this adapter does

How the latency targets were chosen

What counts toward latency

Endpoint reachability and request failures

Scaling and target-service capacity

Data and behavior guarantees

Example and diagnosis

EventBridge to Pub/Sub

EventBridge to PostgreSQL

What this adapter does

How the latency targets were chosen

What counts toward latency

Endpoint reachability and request failures

Scaling and target-service capacity

Data and behavior guarantees

Example and diagnosis