SQS (FIFO)

​

Supported environments

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

​

How the backends compare

​

Cloud Adapter

​

On Akamai, Azure, DigitalOcean, OCI, Private Kubernetes, and Scaleway

​

PostgreSQL

​

PostgreSQL hosting

​

Persistent queue management and total cost

​

Database placement and recovery

​

Capacity and queue workload

​

Retries, batches and application changes

​

PostgreSQL queue behavior

The application keeps its SQS SDK. The adapter stores each queue in a PostgreSQL table.

​

Architecture

Each queue, including each dead-letter queue, is a PostgreSQL table. The same adapter runs on every supported PostgreSQL host.

​

Receiving messages

Two receivers never get the same message at the same time. ApproximateReceiveCount is the actual receive count.

​

Receipt handles & visibility

Receipt handles are saved with messages, so they still work after an adapter restart. Visibility has no lock-duration limit.

​

Dead-letter & retention

Atomic DLQ moves require the same supported SQS-owned database transaction. Cross-store moves are unsupported. Retention cleanup removes aged messages.

​

FIFO ordering & dedup

FIFO receives deliver one message per group at a time. Sends return a SequenceNumber, and repeated sends within 5 minutes are suppressed, matched by an explicit ID or, with content-based deduplication, a body hash.

​

Limitations

• Throughput behaves differently: one PostgreSQL server serves every queue. All of a Cloud Adapter deployment’s queues share one server, so its capacity bounds peak throughput and a heavy queue can affect the others. In Tensor9’s round-trip test of a moderate-rate Standard queue, the adapter matched SQS throughput (about 300 vs 286 ops/s) with a lower p99 (140 ms vs 172 ms) but a slower median (p50 24 ms vs 15 ms). That is not a measured ceiling, and it does not cover FIFO queues or every host.
• Recovery follows the database placement. CloudNativePG keeps queue data on the Cloud Adapter deployment cluster’s volumes. Rebuilding the cluster requires explicit data recovery or a drained cutover.
• Messages are limited to 256 KiB by default. The adapter’s default limit is 262144 bytes, while native SQS now accepts up to 1 MiB. Sends are checked against the queue’s declared limit.
• FIFO send deduplication lasts 5 minutes. A duplicate send within that window returns the original IDs. Reusing an ID after the window can create a new message. Consumer redelivery remains possible even within the window.
• Stale receipt handles behave differently: they return an error. DeleteMessage and ChangeMessageVisibility return ReceiptHandleIsInvalid when no message matches the handle.
• Retention behaves differently: expired messages are removed periodically. An expired message can remain until the next cleanup pass. Retention is kept between 60 seconds and 14 days; a too-short value is raised to 60 seconds so that new messages are not deleted.
• Counts observe queue state, not application completion. Requested message counts read the message database: eligible messages are visible, future-visible messages with a receipt are in flight, and future-visible messages without a receipt are initially delayed. These categories share one query snapshot and can change immediately afterward. Metadata-only reads do not require a message-table count. An unavailable requested count returns an explicit unsupported result rather than zero. Purge, expiry and dead-letter movement can reduce depth without completing the application’s work.
• Queue creation behaves differently: queues are created when the stack is deployed. Tensor9 creates the database and each queue’s table, and its dead-letter table, at deploy time. CreateQueue, DeleteQueue and SetQueueAttributes act on those tables. Switching a queue between Standard and FIFO is rejected, because it would replace the queue.

​

Other considerations

• Moving from AWS. The database and queue tables start empty, and existing SQS messages are not migrated. Drain each group before switching it, to preserve order.
• Removing queues. Each queue is created in one step, so a crash never leaves a half-created queue. When a queue is removed from the stack, Tensor9 deletes only queues it created; any other queue is detached and left in place. A queue that still holds messages is not deleted unless deletion is forced.
• Who operates what. On the managed hosts, the provider operates the database’s durability, backups and high availability, and Tensor9 operates the adapter. On CloudNativePG, Tensor9 operates the database inside your cluster.

​

Example monthly charges

SQS FIFO · SQS request billing units

• 1-KiB messages, unbatched send/receive/delete; actual batch and delivery assumptions stay visible. 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: FIFO request-processing service levels have not been qualified for this mapping. Standard-queue measurements do not establish FIFO latency, throughput or availability.
• 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• 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, AWSQueueService offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSQueueService/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

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

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

• 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: FIFO request-processing service levels have not been qualified for this mapping. Standard-queue measurements do not establish FIFO latency, throughput or availability.
• 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• 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.

​

On Azure

​

Azure Service Bus

​

Persistent queue management and total cost

​

Service Bus capacity and queue lifetime

​

FIFO with PostgreSQL authority and broker wakeups

​

How it works

The application keeps its SQS SDK. A Tensor9 adapter translates FIFO queue calls to Service Bus sessions.

​

Architecture

Each session is one MessageGroupId , so each group keeps strict order with one message in flight.

​

How sessions preserve group order

• One message in flight per group. A group’s next message is delivered only after the current one is deleted, as with the PostgreSQL FIFO option. This limits a single group to one message per round trip, in exchange for strict order.
• A slow consumer keeps its group. The adapter renews the session lock while your visibility timeout runs. ChangeMessageVisibility with a longer timeout renews the lock; zero makes the message available again at once, in order.
• Receive counts stay accurate. When the adapter gives up a session, it first releases the in-flight message so its delivery count goes up, moving a failing message toward its redrive limit instead of resetting it. It also receives no more messages than the remaining MaxNumberOfMessages, so no message is received and dropped, which would raise its count.

Service Bus gives each group’s session to exactly one consumer, so order holds as you add consumer pods.

​

Duplicate detection

The adapter uses the MessageDeduplicationId, or a body hash, as the Service Bus message ID. Service Bus drops repeats within 5 minutes.

​

Dead-lettering

Service Bus forwards messages that reach maxReceiveCount to your declared DLQ, where the adapter can receive them.

​

Limitations

• Duplicate sends behave differently: the dropped send returns a new MessageId. SQS returns the original message’s MessageId (and SequenceNumber) for a duplicate. Here the duplicate is still dropped (consumers can still get redeliveries), but its response contains a new ID that matches no delivered message. Do not wait for that ID.
• SequenceNumber is not returned on send. Service Bus cannot return its sequence number when a message is sent. Receive responses include it; it increases across the queue, and so within each group.
• Visibility timeouts above 5 minutes are not supported. The visibility timeout maps to the session lock, which Tensor9 sets to 5 minutes, ten times the adapter’s renewal interval. A longer value returns an error rather than being shortened. ChangeMessageVisibility renews the lock.
• Receipt handles behave differently: they stop working when the adapter restarts. A handle needs a live session lock. After a restart, old handles are invalid, and the group’s in-flight message is delivered again, in order, when its session lock expires, within 5 minutes.
• Expiry behaves differently: it can affect a whole session. SQS retention applies to each message. On Service Bus, an expired message at the front can expire its whole session. Expired messages are dead-lettered and can be recovered from the DLQ, but more may expire together than on SQS.
• Single-group throughput behaves differently: one message per round trip. Strict order allows one message in flight per group, against up to 10 per receive on SQS. Total throughput grows with the number of groups, so parallelism comes from many groups, not from batching within one.
• Receives on an empty queue behave differently: they can wait longer than WaitTimeSeconds. Service Bus controls how long accepting a session takes, and the adapter never cancels it partway, because that could leave a session lock held. A FIFO receive on an empty queue can overrun its wait by up to one accept window, about 60 seconds at worst; your monitoring shows the real figure on Azure.
• Per-message DelaySeconds is not supported. It is rejected, as SQS rejects it on a FIFO queue, because a delayed message would arrive after later messages in its group. For queue-level settings, Cloud Adapter manages the logical queue settings, but the messaging backend rejects a nonzero queue delay and new dead-letter routes.
• You must drain a queue before changing its FIFO or deduplication settings. Sessions and duplicate detection are fixed when the queue is created. Changing between standard and FIFO, or turning content-based deduplication on or off, deletes and re-creates the queue and loses its messages. Every FIFO build warns about this.
• Sends without a deduplication ID behave differently: they are accepted. SQS requires MessageDeduplicationId when content-based deduplication is off. The adapter cannot read that setting with its messaging permissions, so it accepts the send. Group order is kept, but you do not get the SQS validation error.

​

Other considerations

• Moving from AWS. The Service Bus namespace and queue start empty, and messages in SQS are not migrated. Switch over when the queue is drained, or write to both queues for a while, and drain each group so none switches partway through.
• Who operates what. Tensor9 creates the namespace and the queue, configured as described under Architecture, from your queue declarations, and runs the adapter next to your application. The declared maxReceiveCount sets when messages are forwarded to the DLQ. Microsoft operates Service Bus Standard: durability, backups and high availability. You operate the Azure subscription, cluster patching and monitoring. Sending and receiving need no queue-management credential.
• FIFO must be selected explicitly. Older deployments that used the earlier combined SQS-to-Service-Bus option supported standard queues only. Tensor9 does not convert them to FIFO; declare and select a FIFO queue to use sessions.

​

Example monthly charges

SQS FIFO · SQS request billing units

• 1-KiB messages, unbatched send/receive/delete; actual batch and delivery assumptions stay visible. 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.
• 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• Azure Service Bus Standard bills a namespace base charge that includes 13 million operations a month, then graduated per-operation prices: USD 0.80 per million to 100 million, 0.50 to 2,500 million and 0.20 beyond. An operation is any API call (send, receive, complete) per 64 KB of message; the family’s managed operations count calls, not 64 KB units. Standard has no storage charge (queue size quota up to 5 GB is included). More than 1,000 brokered connections bill USD 0.03 per connection-month, which this profile does not model.
• AWS Price List API, AWSQueueService offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSQueueService/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices

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

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

• 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• Azure Service Bus Standard bills a namespace base charge that includes 13 million operations a month, then graduated per-operation prices: USD 0.80 per million to 100 million, 0.50 to 2,500 million and 0.20 beyond. An operation is any API call (send, receive, complete) per 64 KB of message; the family’s managed operations count calls, not 64 KB units. Standard has no storage charge (queue size quota up to 5 GB is included). More than 1,000 brokered connections bill USD 0.03 per connection-month, which this profile does not model.

​

Azure Cosmos DB (queue)

​

How Cosmos serves SQS FIFO

​

Send, duplicate suppression and uncertain results

​

Ordered receive, durable receipts and batch restrictions

​

Persistent queue management and total cost

​

Cosmos capacity and partition choice

​

Transactional Cosmos FIFO and lifecycle

​

Deployment, security and application changes

​

Example monthly charges

SQS FIFO · SQS request billing units

• 1-KiB messages, unbatched send/receive/delete; actual batch and delivery assumptions stay visible. 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.
• 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• Azure Cosmos DB provisioned throughput bills 100-RU/s blocks per hour and stored GB-months; operations within the provisioned RU/s have no separate charge. Blocks are sized from the family’s reads at 1 RU and writes at 5.5 RU (1 KB items, no extra indexing) at full utilization after the planning peak factor, with the 400 RU/s smallest manual allocation as the floor (USD 23.36/month). Larger messages, indexing and query-based receives raise the RU charge; autoscale (USD 0.012 per 100 RU/s-hour) and serverless (USD 0.25 per million RUs) are not selected.
• AWS Price List API, AWSQueueService offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSQueueService/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices

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

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

• 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• Azure Cosmos DB provisioned throughput bills 100-RU/s blocks per hour and stored GB-months; operations within the provisioned RU/s have no separate charge. Blocks are sized from the family’s reads at 1 RU and writes at 5.5 RU (1 KB items, no extra indexing) at full utilization after the planning peak factor, with the 400 RU/s smallest manual allocation as the floor (USD 23.36/month). Larger messages, indexing and query-based receives raise the RU charge; autoscale (USD 0.012 per 100 RU/s-hour) and serverless (USD 0.25 per million RUs) are not selected.

​

PostgreSQL Flexible Server

​

PostgreSQL hosting

​

Persistent queue management and total cost

​

Database placement and recovery

​

Capacity and queue workload

​

Retries, batches and application changes

​

PostgreSQL queue behavior

The application keeps its SQS SDK. The adapter stores each queue in a PostgreSQL table.

​

Architecture

Each queue, including each dead-letter queue, is a PostgreSQL table. The same adapter runs on every supported PostgreSQL host.

​

Receiving messages

Two receivers never get the same message at the same time. ApproximateReceiveCount is the actual receive count.

​

Receipt handles & visibility

Receipt handles are saved with messages, so they still work after an adapter restart. Visibility has no lock-duration limit.

​

Dead-letter & retention

Atomic DLQ moves require the same supported SQS-owned database transaction. Cross-store moves are unsupported. Retention cleanup removes aged messages.

​

FIFO ordering & dedup

FIFO receives deliver one message per group at a time. Sends return a SequenceNumber, and repeated sends within 5 minutes are suppressed, matched by an explicit ID or, with content-based deduplication, a body hash.

​

Limitations

• Throughput behaves differently: one PostgreSQL server serves every queue. All of a Cloud Adapter deployment’s queues share one server, so its capacity bounds peak throughput and a heavy queue can affect the others. In Tensor9’s round-trip test of a moderate-rate Standard queue, the adapter matched SQS throughput (about 300 vs 286 ops/s) with a lower p99 (140 ms vs 172 ms) but a slower median (p50 24 ms vs 15 ms). That is not a measured ceiling, and it does not cover FIFO queues or every host.
• Recovery follows the database placement. The managed database is outside the Cloud Adapter deployment cluster, so replacing that cluster does not replace the queue data. Database availability and recovery still depend on the selected server, HA and backup configuration.
• Messages are limited to 256 KiB by default. The adapter’s default limit is 262144 bytes, while native SQS now accepts up to 1 MiB. Sends are checked against the queue’s declared limit.
• FIFO send deduplication lasts 5 minutes. A duplicate send within that window returns the original IDs. Reusing an ID after the window can create a new message. Consumer redelivery remains possible even within the window.
• Stale receipt handles behave differently: they return an error. DeleteMessage and ChangeMessageVisibility return ReceiptHandleIsInvalid when no message matches the handle.
• Retention behaves differently: expired messages are removed periodically. An expired message can remain until the next cleanup pass. Retention is kept between 60 seconds and 14 days; a too-short value is raised to 60 seconds so that new messages are not deleted.
• Counts observe queue state, not application completion. Requested message counts read the message database: eligible messages are visible, future-visible messages with a receipt are in flight, and future-visible messages without a receipt are initially delayed. These categories share one query snapshot and can change immediately afterward. Metadata-only reads do not require a message-table count. An unavailable requested count returns an explicit unsupported result rather than zero. Purge, expiry and dead-letter movement can reduce depth without completing the application’s work.
• Queue creation behaves differently: queues are created when the stack is deployed. Tensor9 creates the database and each queue’s table, and its dead-letter table, at deploy time. CreateQueue, DeleteQueue and SetQueueAttributes act on those tables. Switching a queue between Standard and FIFO is rejected, because it would replace the queue.

​

Other considerations

• Moving from AWS. The database and queue tables start empty, and existing SQS messages are not migrated. Drain each group before switching it, to preserve order.
• Removing queues. Each queue is created in one step, so a crash never leaves a half-created queue. When a queue is removed from the stack, Tensor9 deletes only queues it created; any other queue is detached and left in place. A queue that still holds messages is not deleted unless deletion is forced.
• Who operates what. On the managed hosts, the provider operates the database’s durability, backups and high availability, and Tensor9 operates the adapter. On CloudNativePG, Tensor9 operates the database inside your cluster.

​

Example monthly charges

SQS FIFO · SQS request billing units

• 1-KiB messages, unbatched send/receive/delete; actual batch and delivery assumptions stay visible. 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• 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, AWSQueueService offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSQueueService/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices

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

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

• 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• 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.

​

On Google Cloud

​

Cloud SQL for PostgreSQL

​

PostgreSQL hosting

​

Persistent queue management and total cost

​

Database placement and recovery

​

Capacity and queue workload

​

Retries, batches and application changes

​

PostgreSQL queue behavior

The application keeps its SQS SDK. The adapter stores each queue in a PostgreSQL table.

​

Architecture

Each queue, including each dead-letter queue, is a PostgreSQL table. The same adapter runs on every supported PostgreSQL host.

​

Receiving messages

Two receivers never get the same message at the same time. ApproximateReceiveCount is the actual receive count.

​

Receipt handles & visibility

Receipt handles are saved with messages, so they still work after an adapter restart. Visibility has no lock-duration limit.

​

Dead-letter & retention

Atomic DLQ moves require the same supported SQS-owned database transaction. Cross-store moves are unsupported. Retention cleanup removes aged messages.

​

FIFO ordering & dedup

FIFO receives deliver one message per group at a time. Sends return a SequenceNumber, and repeated sends within 5 minutes are suppressed, matched by an explicit ID or, with content-based deduplication, a body hash.

​

Limitations

• Throughput behaves differently: one PostgreSQL server serves every queue. All of a Cloud Adapter deployment’s queues share one server, so its capacity bounds peak throughput and a heavy queue can affect the others. In Tensor9’s round-trip test of a moderate-rate Standard queue, the adapter matched SQS throughput (about 300 vs 286 ops/s) with a lower p99 (140 ms vs 172 ms) but a slower median (p50 24 ms vs 15 ms). That is not a measured ceiling, and it does not cover FIFO queues or every host.
• Recovery follows the database placement. The managed database is outside the Cloud Adapter deployment cluster, so replacing that cluster does not replace the queue data. Database availability and recovery still depend on the selected server, HA and backup configuration.
• Messages are limited to 256 KiB by default. The adapter’s default limit is 262144 bytes, while native SQS now accepts up to 1 MiB. Sends are checked against the queue’s declared limit.
• FIFO send deduplication lasts 5 minutes. A duplicate send within that window returns the original IDs. Reusing an ID after the window can create a new message. Consumer redelivery remains possible even within the window.
• Stale receipt handles behave differently: they return an error. DeleteMessage and ChangeMessageVisibility return ReceiptHandleIsInvalid when no message matches the handle.
• Retention behaves differently: expired messages are removed periodically. An expired message can remain until the next cleanup pass. Retention is kept between 60 seconds and 14 days; a too-short value is raised to 60 seconds so that new messages are not deleted.
• Counts observe queue state, not application completion. Requested message counts read the message database: eligible messages are visible, future-visible messages with a receipt are in flight, and future-visible messages without a receipt are initially delayed. These categories share one query snapshot and can change immediately afterward. Metadata-only reads do not require a message-table count. An unavailable requested count returns an explicit unsupported result rather than zero. Purge, expiry and dead-letter movement can reduce depth without completing the application’s work.
• Queue creation behaves differently: queues are created when the stack is deployed. Tensor9 creates the database and each queue’s table, and its dead-letter table, at deploy time. CreateQueue, DeleteQueue and SetQueueAttributes act on those tables. Switching a queue between Standard and FIFO is rejected, because it would replace the queue.

​

Other considerations

• Moving from AWS. The database and queue tables start empty, and existing SQS messages are not migrated. Drain each group before switching it, to preserve order.
• Removing queues. Each queue is created in one step, so a crash never leaves a half-created queue. When a queue is removed from the stack, Tensor9 deletes only queues it created; any other queue is detached and left in place. A queue that still holds messages is not deleted unless deletion is forced.
• Who operates what. On the managed hosts, the provider operates the database’s durability, backups and high availability, and Tensor9 operates the adapter. On CloudNativePG, Tensor9 operates the database inside your cluster.

​

Google Cloud queue designs

​

Example monthly charges

SQS FIFO · SQS request billing units

• 1-KiB messages, unbatched send/receive/delete; actual batch and delivery assumptions stay visible. 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: FIFO request-processing service levels have not been qualified for this mapping. Standard-queue measurements do not establish FIFO latency, throughput or availability.
• 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• 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, AWSQueueService offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSQueueService/current/us-east-1/index.json
• Cloud SQL pricing: https://cloud.google.com/sql/pricing

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

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

• 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: FIFO request-processing service levels have not been qualified for this mapping. Standard-queue measurements do not establish FIFO latency, throughput or availability.
• 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• 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.

​

On Scaleway

​

Scaleway Managed Database for PostgreSQL

​

PostgreSQL hosting

​

Persistent queue management and total cost

​

Database placement and recovery

​

Capacity and queue workload

​

Retries, batches and application changes

​

PostgreSQL queue behavior

The application keeps its SQS SDK. The adapter stores each queue in a PostgreSQL table.

​

Architecture

Each queue, including each dead-letter queue, is a PostgreSQL table. The same adapter runs on every supported PostgreSQL host.

​

Receiving messages

Two receivers never get the same message at the same time. ApproximateReceiveCount is the actual receive count.

​

Receipt handles & visibility

Receipt handles are saved with messages, so they still work after an adapter restart. Visibility has no lock-duration limit.

​

Dead-letter & retention

Atomic DLQ moves require the same supported SQS-owned database transaction. Cross-store moves are unsupported. Retention cleanup removes aged messages.

​

FIFO ordering & dedup

FIFO receives deliver one message per group at a time. Sends return a SequenceNumber, and repeated sends within 5 minutes are suppressed, matched by an explicit ID or, with content-based deduplication, a body hash.

​

Limitations

• Throughput behaves differently: one PostgreSQL server serves every queue. All of a Cloud Adapter deployment’s queues share one server, so its capacity bounds peak throughput and a heavy queue can affect the others. In Tensor9’s round-trip test of a moderate-rate Standard queue, the adapter matched SQS throughput (about 300 vs 286 ops/s) with a lower p99 (140 ms vs 172 ms) but a slower median (p50 24 ms vs 15 ms). That is not a measured ceiling, and it does not cover FIFO queues or every host.
• Recovery follows the database placement. The managed database is outside the Cloud Adapter deployment cluster, so replacing that cluster does not replace the queue data. Database availability and recovery still depend on the selected server, HA and backup configuration.
• Messages are limited to 256 KiB by default. The adapter’s default limit is 262144 bytes, while native SQS now accepts up to 1 MiB. Sends are checked against the queue’s declared limit.
• FIFO send deduplication lasts 5 minutes. A duplicate send within that window returns the original IDs. Reusing an ID after the window can create a new message. Consumer redelivery remains possible even within the window.
• Stale receipt handles behave differently: they return an error. DeleteMessage and ChangeMessageVisibility return ReceiptHandleIsInvalid when no message matches the handle.
• Retention behaves differently: expired messages are removed periodically. An expired message can remain until the next cleanup pass. Retention is kept between 60 seconds and 14 days; a too-short value is raised to 60 seconds so that new messages are not deleted.
• Counts observe queue state, not application completion. Requested message counts read the message database: eligible messages are visible, future-visible messages with a receipt are in flight, and future-visible messages without a receipt are initially delayed. These categories share one query snapshot and can change immediately afterward. Metadata-only reads do not require a message-table count. An unavailable requested count returns an explicit unsupported result rather than zero. Purge, expiry and dead-letter movement can reduce depth without completing the application’s work.
• Queue creation behaves differently: queues are created when the stack is deployed. Tensor9 creates the database and each queue’s table, and its dead-letter table, at deploy time. CreateQueue, DeleteQueue and SetQueueAttributes act on those tables. Switching a queue between Standard and FIFO is rejected, because it would replace the queue.

​

Other considerations

• Moving from AWS. The database and queue tables start empty, and existing SQS messages are not migrated. Drain each group before switching it, to preserve order.
• Removing queues. Each queue is created in one step, so a crash never leaves a half-created queue. When a queue is removed from the stack, Tensor9 deletes only queues it created; any other queue is detached and left in place. A queue that still holds messages is not deleted unless deletion is forced.
• Who operates what. On the managed hosts, the provider operates the database’s durability, backups and high availability, and Tensor9 operates the adapter. On CloudNativePG, Tensor9 operates the database inside your cluster.

​

Example monthly charges

SQS FIFO · SQS request billing units

• 1-KiB messages, unbatched send/receive/delete; actual batch and delivery assumptions stay visible. 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 → fr-par, 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• Scaleway Managed Database for PostgreSQL at Production Optimized (PRO2) prices in EUR converted at the ECB reference rate. A high-availability or replica node bills Scaleway’s ‘Additional nodes’ price, EUR 0.0583 per hour for PRO2-XXS, 53% of the main node. Scaleway lists no egress charge for Managed Databases, so selected network is not charged. Cost Optimized ranges (DB-DEV-S from EUR 0.0156 per hour), Block Storage 15K and backups (EUR 0.03 per GB-month) 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: DB-PRO2-L has 32 vCPUs and 128 GB (https://www.scaleway.com/en/pricing/managed-databases/); a volume grows up to 15 TB (https://www.scaleway.com/en/docs/managed-databases-for-postgresql-and-mysql/concepts/).
• 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, AWSQueueService offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSQueueService/current/us-east-1/index.json
• Scaleway Managed Databases pricing: https://www.scaleway.com/en/pricing/managed-databases/

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

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

• 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.
• Storage follows resident original messages, not every monthly message. Broker delivery bytes include redeliveries.
• FIFO estimates do not qualify dedup support, group throughput or single-group latency; backend limitations remain applicable.
• Scaleway Managed Database for PostgreSQL at Production Optimized (PRO2) prices in EUR converted at the ECB reference rate. A high-availability or replica node bills Scaleway’s ‘Additional nodes’ price, EUR 0.0583 per hour for PRO2-XXS, 53% of the main node. Scaleway lists no egress charge for Managed Databases, so selected network is not charged. Cost Optimized ranges (DB-DEV-S from EUR 0.0156 per hour), Block Storage 15K and backups (EUR 0.03 per GB-month) 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: DB-PRO2-L has 32 vCPUs and 128 GB (https://www.scaleway.com/en/pricing/managed-databases/); a volume grows up to 15 TB (https://www.scaleway.com/en/docs/managed-databases-for-postgresql-and-mysql/concepts/).
• 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.

​

Costs

​

Service level agreements

​

SQS to Cosmos DB

​

Why these latency targets differ

​

Adapter and scope

​

Receive timing

• Ready-message pickup: time from a message becoming available to a waiting receiver until the adapter sends the response. Only separately measured time spent waiting for the backend service is excluded.
• Delay after the requested wait: extra adapter time after the requested wait for a message has ended.

​

Message guarantees

​

Useful throughput

​

Operation terms

​

Scaling on Cosmos DB

​

Example: two receivers see the same candidate

​

Example: restart during a dead-letter transition

​

Evidence for support

​

SQS (Simple Queue Service, FIFO queues) 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

​

SQS (Simple Queue Service, FIFO queues) to Azure Service Bus

​

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

​

SQS (Simple Queue Service, FIFO queues) to Cloud SQL for PostgreSQL

​

SQS (Simple Queue Service, FIFO queues) to PostgreSQL

​

SQS (Simple Queue Service, FIFO queues) to Scaleway Managed Database 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

​

Install and run

tensor9 adapt svc list \
  -origin aws::1.0.0::sqs::fifo

​

Existing data and credentials

​

Configure, tune and debug