Skip to main content
An email worker, an ordered account-update stream and a twenty-minute export job can all use the SQS API. They need different delivery behavior. Choose a backend by following a message from publication through processing, acknowledgement and recovery. Send throughput alone does not establish those behaviors.

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 as t9:backend on CreateQueue, and inspect the effective choice. Selecting a backend does not move an existing queue’s backlog.
A message moves from enqueue to available, leased and acknowledged. Lease expiry allows redelivery. The application's business commit and the queue acknowledgement are separate operations.A message moves from enqueue to available, leased and acknowledged. Lease expiry allows redelivery. The application's business commit and the queue acknowledgement are separate operations.

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?
The Standard and FIFO profiles define each mapping’s detailed contract. The main choices are:

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 brew upgrade tensor9 for an existing installation:
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.
2

Set the native endpoint and create a disposable queue

In a second terminal, use an isolated test environment where 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.
Expect the declared ten-second visibility and ten-minute retention. 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 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.
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.
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 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:
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.

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 maps MessageGroupId 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 keeps DelaySeconds, 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.

OCI

OCI Queue or CloudNativePG

OCI Queue is a Standard-queue candidate with provider-operated message storage. CloudNativePG provides the documented PostgreSQL-backed Standard and FIFO contracts on cluster storage. Use native Queue as a candidate when jobs fit its payload, retention, visibility and dead-letter behavior. Use the PostgreSQL mapping as a candidate when FIFO or its durable claim and delay semantics are required. Compare the exact contract before measuring cost: the catalog limits OCI Queue retention to seven days, while the PostgreSQL mapping documents the SQS retention range. Neither more consumers nor a larger native quota changes a missing API behavior. For either option, test message redelivery after an adapter restart and downstream outage. For CloudNativePG, add cluster-storage loss and restoration to the test; for OCI Queue, test the configured native dead-letter destination and recovery access.

Akamai

CloudNativePG

The CloudNativePG mapping serves Standard and FIFO queues using durable PostgreSQL messages, claims and deduplication state. It fits workloads that need those SQS behaviors in an Akamai Kubernetes deployment and can operate the corresponding database storage. Budget the shared database for send bursts, empty receives, retained backlog and delayed jobs. A hot FIFO group remains serial even with spare capacity. Cluster-local data does not survive a full cluster rebuild by itself; prepare recovery or drain/cutover procedures before replacing the cluster. There is no second documented backend here to rank against it.

DigitalOcean

CloudNativePG

The documented CloudNativePG target supports the PostgreSQL-backed Standard and FIFO queue contracts. It offers durable queue lifecycle state within the deployment rather than requiring a separate native messaging product. That placement also makes persistent volumes and database recovery part of the application’s availability plan. Compare required backlog retention and drain rate with database capacity and maintenance windows. Choose this mapping when its queue semantics and cluster operating model fit, and qualify it with delayed jobs, live receipts across adapter restarts and an application crash after its business commit.

Private Kubernetes

CloudNativePG for local queue storage

CloudNativePG keeps queue data inside the permitted infrastructure and provides Standard/FIFO delivery through the PostgreSQL queue engine. This can meet disconnected placement requirements when the database, adapter and application dependencies are reachable locally. The deployment must reserve usable storage for retained backlog and recovery, protect claim and deduplication records, and define a tested restore procedure. A restored snapshot can replay a message whose external business effect already happened. Retain application completion records and reconcile those effects; restoring queue storage alone does not establish exactly-once processing.

Next steps

Measure completed jobs, backlog age and drain time under your actual message sizes and group skew. Include poisoned messages and downstream outages. More capacity may reduce contention. It cannot turn one ordered group into independent work, migrate old receipt handles or make an external payment transactional with a queue acknowledgement. Revisit the backend choice when those requirements change. Next, follow Tuning AWS SQS to configure visibility and batching, size backend capacity and measure completed work.