General trade-offs
Fix the target environment before comparing backends. Delivery, ordering, delayed publication and recovery decide which of its adapters can serve the workload. After those requirements fit, compare capacity, total delivery cost and the operating responsibilities of each candidate. A service adapter is a directed origin-to-target mapping: the SQS origin and its target backend together identify the adapter. A single-service trial selects its backend explicitly. In a multi-service installation, use the supported resource-creation selector, such ast9:backend on CreateQueue, and inspect the effective choice. Selecting a backend does not move an existing queue’s backlog.
Decide which behavior matters
Standard queues allow redelivery and do not guarantee order. FIFO preserves order within a message group, not across all groups. Duplicate-send suppression and consumer redelivery are different: a worker can finish a payment and crash before acknowledging the message. Neither queue family makes that payment exactly-once. Answer these questions before comparing candidates:- Are messages independent, or must each customer’s events remain ordered?
- How long does processing take, including time waiting inside a worker?
- Must delivery be delayed before the first receive?
- What happens when an adapter restarts while workers hold receipt handles?
- How are poison messages identified, retained and inspected?
- How much backlog must survive an outage, and how quickly must it drain?
- Who owns capacity, recovery and access to the target resources?
Assign operating responsibility
For a customer-operated installation, agree on this division before production. Tensor9 software managing queue state does not imply a Tensor9-managed operations service.
Rebuildable connections differ from authoritative backlog and deduplication records. Back up and restore the latter coherently. A restored database snapshot can reintroduce messages whose external effects already happened. Link that recovery procedure to the application’s completion records, not only to infrastructure health.
Google Cloud
Pub/Sub or Cloud SQL PostgreSQL
Short jobs in Google Cloud
Suppose an application sends small email jobs, normally finishes each within a minute and tolerates redelivery through a stable job ID. Compare Pub/Sub with Cloud SQL PostgreSQL-backed SQS in the same region. With Pub/Sub, the application keeps its SQS client and send/receive/delete workflow. Cloud Adapter maps the queue to a topic and subscription; Google operates message storage and delivery. There is no dedicated queue database to size. The lease model and request-based costs are part of this mapping’s contract. It accepts visibility values of 10–600 seconds, with zero available for immediate release. Receipt handles depend on the receiving stream; after a restart, receive the message again and use its new handle. Workers must be able to retry safely. Include receive, acknowledgement, empty-work and dead-letter activity alongside publications in the cost comparison. Cloud SQL stores queue state, durable claims and delayed-availability timestamps in PostgreSQL. Its operating model includes a provisioned capacity floor, connections, indexes and maintenance work. Those differences do not establish a throughput or cost ranking; measure both mappings against the same job mix and recovery requirements.
Configure and test the actual dead-letter destination before production. A topic with no receiving subscription is not an incident-review workflow. See Pub/Sub tuning.
Try redelivery and idempotency
This disposable Pub/Sub trial demonstrates visibility expiry and processing one job identity twice. Pub/Sub is the concrete target for this example, not a recommended backend. The trial does not compare throughput, cost or production-handler correctness. Use a test project with queue creation enabled and no other consumers. Native cloud resources can incur charges.1
Prepare the adapter and inspect its contract
Install the Tensor9 CLI, or use Prepare Google Cloud Application Default Credentials plus the test project’s target configuration. The adapter identity needs topic/subscription lifecycle and messaging permissions. Configure a separate origin-facing AWS profile accepted by your installation.Profile inspection is non-executing. Leave the single-binary process running and copy its listening endpoint.
brew upgrade tensor9 for an existing installation:2
Set the native endpoint and create a disposable queue
In a second terminal, use an isolated test environment where Expect the declared ten-second visibility and ten-minute retention.
tradeoffs-jobs does not already exist. SQS creation can return an existing queue, so confirm the name is unused before continuing. Replace the queue URL placeholder below with the value returned by create-queue.AWS_ENDPOINT_URL_SQS affects SQS in this shell. AWS documents this service-specific endpoint variable.3
Receive the same job again after visibility expires
Install Boto3 in an isolated Python environment:Save this as Expected: the same job becomes receivable again, and the local record contains one effect. The 90-second polling window is a test timeout, not a delivery SLA. This in-memory ledger illustrates duplicate handling only; production needs durable idempotency across workers and crashes, including the boundary around external side effects.
sqs-redelivery.py and replace the endpoint with the value printed by Tensor9. It shows the alternative, client-specific endpoint configuration and looks up tradeoffs-jobs by name. The Boto3 receive parameters remain ordinary SQS parameters.4
Interpret the observation and clean up
If redelivery times out, inspect the native subscription, retention, outstanding delivery and competing consumers using Debugging Your Adapters. If your real handler produces two effects, repair its idempotency before accepting the application, regardless of backend choice.To inspect an instrumented request, follow Using Explain and add Verify removal of the trial topic/subscription through their lifecycle owner, then stop the adapter with Control-C. Pre-provisioned resources may have separate ownership. Keep diagnostic evidence if the test failed; do not infer cleanup from an empty receive.
x-t9-explain before signing. The value true executes the request; it is not a preview. A report can identify the selected mapping and recorded path, but a receipt alone does not prove settlement.Stop test consumers. Delete only this trial’s queue:Microsoft Azure
Broker, queue-storage and database options
For independent notifications, compare Queue Storage, Service Bus and the database options using the same message sizes and visibility/retry requirements. For strict groups, restrict the comparison to the FIFO mappings. A PostgreSQL option can change recovery ownership without changing the application’s queue API; managed Flexible Server and cluster-local CloudNativePG have different failure boundaries.
Ordered events in Azure
Consider account updates that must remain ordered within each customer, with independent customers processed concurrently. Compare Service Bus sessions with Azure Database for PostgreSQL Flexible Server-backed FIFO. With Service Bus, Cloud Adapter mapsMessageGroupId to a session and preserves one in-flight message per group. The broker coordinates session ownership across consumers. The application keeps its FIFO group IDs and explicit deduplication IDs.
There are consequential differences. A suppressed duplicate send returns a fresh MessageId, and the send response omits SequenceNumber. Correlate business work with your own event ID. The first message’s expiration can expire other messages in the same session; inspect the dead-letter route and decide whether that retention behavior is acceptable. Receipt handles depend on the live session and do not survive adapter restart.
The PostgreSQL mapping instead provides its documented duplicate-send identities, per-message retention and durable claim state through a queue engine that stores messages and deduplication markers transactionally. Its compute, storage, connection and recovery budgets are part of the comparison. A familiar SQS API does not remove database operations.
Test a hot group alongside many quiet groups. More consumers cannot make two events in one strict group execute simultaneously. Verify that a poisoned head reaches the declared dead-letter destination and lets later events progress. For payments, also test a crash after the charge but before acknowledgement; ordering does not replace application idempotency.
Scaleway
Native Queues, managed PostgreSQL or CloudNativePG
Delayed export jobs in Scaleway
An export service schedules work five minutes after publication and needs a fifteen-minute processing claim. Compare Scaleway Queues with Scaleway Managed Database for PostgreSQL-backed SQS. PostgreSQL’s durable timestamps implement delayed availability and claims, while queue state survives adapter restart. The native Queues mapping does not provide this example’s required delayed-delivery behavior. That is a contract mismatch for the stated workload, not a general ranking: immediate-delivery workloads have different requirements. Visibility is not a substitute for delay: delay precedes the first receive; visibility hides a message after it is received. The application keepsDelaySeconds, ReceiveMessage and DeleteMessage. The price is a database that consumes capacity while idle and shares CPU, storage and connections among its queues. An export burst can affect unrelated queues on the same server. Retention still bounds message lifetime even while a claim is active.
Use sparse service configuration for the pre-provisioned database binding. Queue tags do not resize that shared server. Test an export burst, adapter restart with a live claim and backlog recovery after an outage.