> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Trade-offs in AWS SQS
> Choose an SQS backend around delivery, ordering, processing time and the work your team will operate.
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.
### 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](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic) and [FIFO](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-fifo) profiles define each mapping's detailed contract. The main choices are:
| Backend family | Mechanism | Consequential choice |
| -------------------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Pub/Sub | Topic plus pull subscription | Managed Standard delivery; lease and delayed-delivery behavior must fit the job. |
| Service Bus | Broker queues; sessions for FIFO groups | Broker-managed coordination, with session lifecycle and receipt behavior. |
| PostgreSQL | Durable queue rows, claim state and FIFO deduplication records | More queue lifecycle state survives process loss; database capacity and recovery become part of the queue architecture. |
| Cosmos DB queues | Durable messages and claims in Cosmos containers | Compare request-unit consumption, group distribution and dead-letter movement. |
| Queue Storage, OCI Queue and Scaleway Queues | Native managed queue services | Useful Standard-queue candidates; compare payload envelope, delay and poison-message handling in the exact profile. |
### 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.
| Component | Operating and recovery owner | Capacity, failure and access |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Adapter runtime and configuration | Named platform team deploys, upgrades, receives alerts and restores configuration | Origin-facing access and native credentials; restart consequences follow the selected receipt contract |
| Managed broker | Provider operates the service; platform team provisions/pays, configures entities and responds to backlog/DLQ alerts | Shared namespace or project limits; narrowly scoped lifecycle and messaging permissions |
| PostgreSQL-backed queue | Provider operates managed database infrastructure; platform team sizes, maintains and tests restoration of messages, claims and deduplication state | Shared database failure/connection budget; protect database credentials and backup access |
| Application effects | Application team owns durable idempotency, reconciliation and worker recovery | Restoring queue state can replay already completed work; coordinate with application state |
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
| Backend | Workloads that can use its strengths | Differences to qualify |
| ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| [Pub/Sub](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#pubsub) | Independent Standard-queue jobs that fit the documented lease and delay contract; provider-operated messaging storage | Stream-bound receipt handles, the supported visibility range and delayed-delivery restrictions. This is not a FIFO mapping. |
| [Cloud SQL PostgreSQL](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#cloud-sql-for-postgresql) | Standard or FIFO queues needing the PostgreSQL mapping's durable claims, delayed availability and per-message retention | Provisioned database capacity, shared connections, indexes and recovery. Include queue maintenance and backlog draining in sizing. |
### 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.
| Evaluation record | Comparison |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Candidates | `aws::1.0.0::sqs::classic` to `google::1.0.0::pubsub` or `google::1.0.0::cloudsql::postgresql` |
| Selection mechanism | Explicit in a single-service trial; queue-creation selection in a compatible multi-service installation |
| Contract differences | Pub/Sub has stream-bound receipts and its documented lease range; PostgreSQL stores claim state durably and implements delayed availability |
| Operating owner | Platform team owns adapter deployment, target permissions and alerts; application team owns idempotency and dead-letter response |
| Qualification | Test delayed delivery if required, restart with an outstanding receipt, and compare total delivery cost at idle and under backlog |
| Evidence and next step | Read the [Pub/Sub profile](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#pubsub), then run the lifecycle probe below |
| Migration cost | Start new workers, redirect new jobs, drain the old queue and reconcile job IDs; old receipts stay with the old endpoint |
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](/cloud-adapter/tuning/aws-sqs#pubsub-tune-visibility-batching-and-retries).
### 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.
Install the Tensor9 CLI, or use `brew upgrade tensor9` for an existing installation:
```bash theme={null}
brew tap tensor9ine/tensor9
brew install tensor9
tensor9 --version
```
Prepare Google Cloud Application Default Credentials plus the test project's [target configuration](/cloud-adapter/configuration/files). The adapter identity needs topic/subscription lifecycle and messaging permissions. Configure a separate origin-facing AWS profile accepted by your installation.
```bash theme={null}
tensor9 explain \
-origin aws::1.0.0::sqs::classic \
-target google::1.0.0::pubsub \
-fmt Human
tensor9 adapt svc run \
--origin aws::1.0.0::sqs::classic \
--backend google::1.0.0::pubsub
```
Profile inspection is non-executing. Leave the single-binary process running and copy its listening endpoint.
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`.
```bash theme={null}
export AWS_ENDPOINT_URL_SQS=""
export AWS_PROFILE="adapter-test"
export AWS_REGION="us-east-1"
aws sqs create-queue \
--queue-name tradeoffs-jobs \
--attributes VisibilityTimeout=10,MessageRetentionPeriod=600 \
--tags 't9:backend=google::1.0.0::pubsub' \
--query QueueUrl --output text
aws sqs get-queue-attributes \
--queue-url "" \
--attribute-names VisibilityTimeout MessageRetentionPeriod
```
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](https://docs.aws.amazon.com/sdkref/latest/guide/ss-endpoints-table.html).
Install Boto3 in an isolated Python environment:
```bash theme={null}
python3 -m venv .venv-sqs-tradeoffs
source .venv-sqs-tradeoffs/bin/activate
python -m pip install boto3
```
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](https://docs.aws.amazon.com/boto3/latest/reference/services/sqs/client/receive_message.html) remain ordinary SQS parameters.
```python theme={null}
import json
import os
import sqlite3
import time
import uuid
import boto3
sqs = boto3.client(
"sqs",
endpoint_url="",
region_name=os.environ["AWS_REGION"],
)
queue = sqs.get_queue_url(QueueName="tradeoffs-jobs")["QueueUrl"]
job_id = str(uuid.uuid4())
sqs.send_message(QueueUrl=queue, MessageBody=json.dumps({"jobId": job_id}))
def receive_job():
deadline = time.monotonic() + 90
while time.monotonic() < deadline:
result = sqs.receive_message(
QueueUrl=queue, MaxNumberOfMessages=1,
WaitTimeSeconds=10, VisibilityTimeout=10,
)
for message in result.get("Messages", []):
if json.loads(message["Body"])["jobId"] != job_id:
raise RuntimeError("Unexpected job; inspect this disposable queue")
return message
raise TimeoutError("No delivery observed within the trial window")
first = receive_job()
# Local stand-in for one transactional application effect.
ledger = sqlite3.connect(":memory:")
ledger.execute("CREATE TABLE completed (job_id TEXT PRIMARY KEY)")
def handle(message):
with ledger:
ledger.execute(
"INSERT OR IGNORE INTO completed VALUES (?)",
(json.loads(message["Body"])["jobId"],),
)
handle(first)
# Simulate processing completed, but DeleteMessage never happened.
time.sleep(12)
second = receive_job()
handle(second)
assert ledger.execute("SELECT COUNT(*) FROM completed").fetchone()[0] == 1
sqs.delete_message(QueueUrl=queue, ReceiptHandle=second["ReceiptHandle"])
ledger.close()
print("Observed redelivery; two handler calls recorded one local effect.")
```
```bash theme={null}
python sqs-redelivery.py
```
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.
If redelivery times out, inspect the native subscription, retention, outstanding delivery and competing consumers using [Debugging Your Adapters](/cloud-adapter/debugging/overview). 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](/cloud-adapter/debugging/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:
```bash theme={null}
aws sqs delete-queue --queue-url ""
unset AWS_ENDPOINT_URL_SQS
deactivate
```
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
| Backend | Workloads that can use its strengths | Differences to qualify |
| ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| [Queue Storage](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#azure-queue-storage) | Independent Standard-queue jobs using native storage queues | Payload envelope, visibility receipts and poison-message handling in this profile; no FIFO mapping. |
| [Service Bus](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-fifo#azure-service-bus) | Standard jobs or per-group FIFO processing using broker-managed queues and sessions | Namespace capacity, session expiry, duplicate-send response identities and receipt loss on adapter restart. |
| [Cosmos DB queue](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-fifo#azure-cosmos-db-queue) | Standard or FIFO processing whose durable message/claim model fits a Cosmos deployment | Request-unit work, partition/group skew and the documented dead-letter movement behavior. |
| [PostgreSQL Flexible Server](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-fifo#postgresql-flexible-server) | Standard or FIFO jobs needing PostgreSQL's durable queue lifecycle outside the application cluster | Shared managed-server capacity, connections, maintenance and restoration of queue and deduplication records. |
| [CloudNativePG](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-fifo#cloudnativepg) | The PostgreSQL queue contract with database placement inside the deployment's Kubernetes cluster | Cluster volumes hold queue state; a full cluster rebuild needs a recovery or queue-cutover procedure. |
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.
| Evaluation record | Comparison |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Candidates | `aws::1.0.0::sqs::fifo` to `azure::1.0.0::servicebus` or `azure::1.0.0::postgresql::flexible` |
| Resource preparation | Service Bus requires session-enabled entities and shares namespace capacity; PostgreSQL requires a database binding and capacity for queue state |
| Contract differences | Compare session versus per-message retention, duplicate-send responses, receipt durability and lock renewal |
| Operating owner | Platform team owns entities, adapter and namespace alerts; application team owns groups, poison handling and idempotency |
| Qualification | Exercise session expiry, a duplicate send, restart with a live receipt and poison-message handling on each eligible mapping |
| Evidence and next step | Compare the [FIFO profiles](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-fifo) and [FIFO configuration examples](/cloud-adapter/tuning/aws-sqs#fifo-concurrency-and-deduplication) |
| Migration cost | Drain or fence each old group before releasing its new-route events; two active queues do not establish one ordering boundary |
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
| Backend | Workload fit | Trade-offs to account for |
| --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| [Scaleway Queues](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#scaleway-queues-sqs-compatible) | Standard jobs that meet its native queue and immediate-delivery contract | Do not infer FIFO or delayed delivery from SQS protocol compatibility. Test visibility and poison-message behavior. |
| [Managed PostgreSQL](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#scaleway-managed-database-for-postgresql) | Standard or FIFO jobs needing durable claims and delayed availability on provider-managed database infrastructure | Provisioned capacity and connection/maintenance budgets shared across queues. |
| [CloudNativePG](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#cloudnativepg) | The PostgreSQL queue contract where storage belongs inside the Kubernetes deployment | Persistent volumes, spare capacity and cluster-loss recovery become part of queue operation. |
### 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.
| Evaluation record | Comparison |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Candidates | Standard queues backed by `scaleway::1.0.0::rdb::postgresql` or `scaleway::1.0.0::queues` |
| Resource preparation | PostgreSQL needs a database and secret-backed connection; native Queues needs the target queue configuration and permissions |
| Contract constraint | PostgreSQL implements delayed availability; the native Queues mapping does not meet the stated delay requirement |
| Operating owner | Platform team owns sizing, credentials and tested restore; Scaleway operates the managed server; application team owns export completion |
| Workload variation | For immediate, short jobs, compare native Queues and PostgreSQL delivery behavior, capacity, recovery and total cost without assuming either is cheaper |
| Evidence and next step | Read the [Standard catalog](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic) and [PostgreSQL preparation/examples](/cloud-adapter/tuning/aws-sqs#postgresql-for-delayed-or-long-running-work) |
| Migration cost | Drain delayed jobs or preserve their availability times in a controlled transfer; document old work before enabling new producers |
Use [sparse service configuration](/cloud-adapter/configuration/files#when-to-add-a-service-entry) 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](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#oci-queue) is a Standard-queue candidate with provider-operated message storage. [CloudNativePG](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#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](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#cloudnativepg) 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](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-fifo#cloudnativepg) 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](/cloud-adapter/service-catalog/aws/messaging-streaming/sqs-classic#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](/cloud-adapter/tuning/aws-sqs) to configure visibility and batching, size backend capacity and measure completed work.