An SQS queue q becomes a Pub/Sub topic q and subscription q-sub . The application calls the adapter through its existing SQS SDK.
#### Architecture The Rust adapter authenticates to Pub/Sub with the customer's Workload Identity, without static credentials. Pub/Sub stores durable messages. The Max queue catalog stores declared configuration; receive buffers and acknowledgement handles belong to each adapter process and do not survive a restart. Google operates Pub/Sub's durability, delivery and high availability; Tensor9 operates the adapter. Per queue, the adapter keeps two long-lived structures. First, a **Publisher per topic**, created on the first send and held for the process lifetime: it feeds Pub/Sub's client-side batching layer, so concurrent sends to the same topic naturally coalesce into one `Publish` RPC rather than one RPC per `SendMessage`. Second, a **StreamingPull consumer per subscription**: a background task holds the subscription's message stream and forwards each received message into a **bounded in-process channel**, which `ReceiveMessage` drains, instead of issuing a blocking pull on every call. On `DeleteQueue` both are dropped; the consumer disposes its stream, which nacks any still-buffered messages so they redeliver promptly rather than waiting out the full deadline. * **Pub/Sub stores durable state.** Messages remain in Pub/Sub when an adapter restarts; local buffers and stream-scoped acknowledgement handles do not. Unacknowledged messages can be redelivered. * **Two limits control buffering.** Pub/Sub limits the number of delivered messages awaiting acknowledgement. The adapter separately limits its in-process receive buffer so idle consumers do not hold an unbounded number of messages whose acknowledgement deadlines are running.
Pub/Sub stores durable messages. The adapter keeps a local receive buffer and stream-scoped acknowledgement handles.
#### Receiving messages A background `StreamingPull` consumer reads the subscription continuously and puts messages in a bounded buffer. `ReceiveMessage` reads that buffer. If a message arrives while the call is waiting, it can return immediately without waiting for another poll. `WaitTimeSeconds` sets how long to wait for the first message, capped at 20 seconds. Zero checks once without blocking; an empty result is valid. After the first message arrives, the adapter fills the rest of the batch from buffered messages without waiting again. `MaxNumberOfMessages` is clamped to 1–10. Pub/Sub limits unacknowledged messages, and the adapter's bounded buffer absorbs short interruptions in receiving while limiting messages held during idle periods. The adapter reconstructs attributes and recomputes MD5 checksums for SDK verification. Use Google Cloud monitoring to size the receive buffer and identify publish or delivery bottlenecks.
ReceiveMessage reads the StreamingPull buffer and waits up to WaitTimeSeconds for the first message, capped at 20 seconds. A message arriving during the wait can return immediately.
#### Visibility & receipt handles `VisibilityTimeout` maps to Pub/Sub's acknowledgement deadline. Queue defaults must be 10–600 seconds. `ReceiveMessage` overrides and `ChangeMessageVisibility` accept that range plus zero, which makes the message available immediately. Other values are rejected, not clamped. A per-call `ReceiveMessage` override updates the returned messages only when it differs from the stream default. The subscriber does not automatically extend deadlines, so a message left in the buffer past its deadline can be delivered again. Consumers must handle duplicate delivery. The receipt handle is the Pub/Sub acknowledgement ID. It remains valid only while the `StreamingPull` consumer that received it is alive. `DeleteQueue`, `PurgeQueue` or a stream error disposes that consumer; the next receive starts a new one. Previously issued handles then stop resolving. Retained, unacknowledged messages can be delivered again with new handles; deleted, purged or retention-expired messages are not promised to return. Receive those messages again before deleting or extending them. `DeleteMessage` acknowledges one ID; batch delete acknowledges the IDs together.
Queue visibility defaults must be 10-600 seconds. Per-message visibility also accepts 0 for immediate redelivery; other values are rejected. Receipt handles are stream-scoped Pub/Sub acknowledgement IDs and do not survive a restart.
#### Dead-letter & delivery Pub/Sub handles dead-letter delivery. The SQS `RedrivePolicy` sets the subscription's delivery-attempt limit from `maxReceiveCount`. The adapter resolves `deadLetterTargetArn`, supplied as an SQS-style ARN or bare name, to `projects/
Pub/Sub forwards messages to a dead-letter topic on a best-effort basis. Delivery-attempt counts require a correctly configured policy and IAM permissions.
#### Limitations **Message size.** The managed adapter checks the declared `MaximumMessageSize` before publishing, including each entry of a batch. Its default is 262144 bytes (256 KiB), below [native SQS's 1 MiB limit](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html). Pub/Sub's native 10 MB limit does not increase the queue's declared allowance. **Retention.** Queue creation and `SetQueueAttributes` apply `MessageRetentionPeriod` to Pub/Sub's subscription retention. Pub/Sub requires at least ten minutes, so shorter SQS retention values are rejected. The remaining SQS range, through 14 days, is representable. Configuration reads use the queue catalog rather than substituting Pub/Sub's default lifetime. △ Pub/Sub limitations * **Approximate message counts are not reported.** Pub/Sub does not expose approximate depth cheaply, so `ApproximateNumberOfMessages`, `...NotVisible`, and `...Delayed` come back empty. Depth is for GCP monitoring once this is running. * **Ack-deadlines are not auto-extended.** The StreamingPull subscriber does not renew a delivered message's lease; the queue default must be 10-600 seconds. A message buffered past its deadline can be delivered again; consumers must tolerate duplicates. * **Receipt handles are stream-scoped, not restart-durable.** The receipt handle is the opaque Pub/Sub ack-id; it stops resolving after `DeleteQueue`, `PurgeQueue`, or a stream error. Retained, unacknowledged messages can be delivered again under a fresh ack-id. * **ApproximateReceiveCount requires a configured dead-letter policy.** It is Pub/Sub's delivery-attempt count, which Pub/Sub supplies only with a correctly configured policy and IAM permissions; the count can reset. A plain queue reports `1` on every receive. * **Nonzero delay is rejected.** Pub/Sub cannot schedule individual messages for later delivery. Queue- and message-level `DelaySeconds` must be zero.
The queue catalog supplies the size limit and retention setting; the adapter enforces size and configures subscription retention.
#### Other considerations * **Plan message cutover.** The Pub/Sub topic `q` and subscription `q-sub` start empty. Existing SQS messages are not migrated. Drain the source queue or dual-write during the transition; application SQS calls and checksum verification remain unchanged. * **Google operates Pub/Sub.** Google manages message durability, delivery and availability. Tensor9 operates the SQS adapter. * **Published messages remain in Pub/Sub.** The adapter keeps a bounded receive buffer in memory. On orderly stream disposal it releases buffered messages for redelivery. After an abrupt failure, unacknowledged messages can be delivered again when their deadlines expire. * **Estimate Pub/Sub costs from message volume.** Billing follows the volume of data sent through Pub/Sub. The adapter does not meter additional usage. * **Operational numbers come from GCP monitoring.** Approximate message counts (`ApproximateNumberOfMessages` and its siblings) come back empty and live latency, throughput, and cost are read from GCP monitoring once the workload is running, so point dashboards and alerts at Pub/Sub's metrics, not SQS CloudWatch queue metrics. ### Via Cloud SQL for PostgreSQL | Operation | Area | Support | Depth | Notes | | ----------------------- | -------------- | --------- | ---------- | ------------------------------------------------------------------------------------------------ | | Dead-letter redrive | Dead-letter | Supported | Most usage | fires automatically once a message passes maxReceiveCount | | Message attributes | Messages | Supported | Common | - | | GetQueueAttributes | Queues | Supported | Most usage | reads queue attributes, including approximate message counts | | GetQueueUrl | Queues | Supported | Most usage | resolves the queue by name | | DelaySeconds | Send / receive | Supported | Common | a delayed message remains hidden until its delay expires | | DeleteMessage | Send / receive | Supported | Common | resolves by receipt handle; a stale handle returns ReceiptHandleIsInvalid | | DeleteMessageBatch | Send / receive | Supported | Common | returns the result for each entry | | ReceiveMessage | Send / receive | Supported | Common | long-poll (WaitTimeSeconds) honored; claims the oldest visible messages | | SendMessage | Send / receive | Supported | Common | supports both SQS protocol formats; MD5 checksums match, identical to the portable Postgres tier | | SendMessageBatch | Send / receive | Supported | Common | up to 10 messages per call; returns the result for each entry | | ChangeMessageVisibility | Visibility | Supported | Common | resolves by receipt handle; a stale handle is rejected rather than silently succeeding | #### PostgreSQL hosting Google operates Cloud SQL for PostgreSQL, including database backups and HA. The adapter uses short-lived Cloud SQL IAM tokens as database passwords, without an Auth Proxy or static password. Queue data stays outside the customer's Kubernetes cluster and survives its rebuild. Tensor9 operates the queue schema and adapter. Queues start empty; existing SQS messages are not migrated. Drain the source or coordinate dual writes before cutover. #### PostgreSQL queue behavior Tensor9 adds an adapter, a proxy process, to your application pod and sets `AWS_ENDPOINT_URL_SQS` to its loopback address. Your application keeps its `SendMessage` and `ReceiveMessage` calls. The adapter implements them using PostgreSQL and returns SQS responses, error codes and MD5 checksums. Each queue has a durable PostgreSQL table with one row per message. SQL operations implement sending, receiving, deletion, delay, visibility, dead-letter delivery and counts. Standard queues provide at-least-once delivery with best-effort ordering.
The application keeps its SQS SDK. The adapter stores each queue in a PostgreSQL table.
#### Architecture The Rust adapter stores all durable state in PostgreSQL, including messages, claims and receipt handles. Instances can restart or scale out without a shared in-memory lock table, receiver pool or renewal loop. On Cloud SQL and Azure Flexible Server, it authenticates with short-lived Cloud SQL IAM or Microsoft Entra tokens generated in-process and passed as database passwords, without a static secret. On the Postgres side, the compiler provisions **one database per appliance**, a catalog entry per queue, and **one durable table per declared queue**. Each message is a row holding the SQS body and its attributes, its message-group, a visibility deadline, a receipt handle, a receive count, and a sent-at timestamp; the table is indexed so the hot paths stay a single scan. A Standard queue claims eligible messages in arrival order, with best-effort ordering under concurrent traffic. A **dead-letter** queue is another queue table, and a background **retention reaper** physically removes rows past their retention. CloudNativePG, Cloud SQL for PostgreSQL and Azure Flexible Server use the same adapter code and tables. Their operational difference is where data is stored: the managed servers are outside the appliance cluster, while CloudNativePG is inside it. See the rebuild limitation below.
Each queue uses a PostgreSQL table, including dead-letter queues. The same adapter code runs against CloudNativePG, Cloud SQL for PostgreSQL and Azure Flexible Server.
#### Receiving messages In one SQL operation, the adapter selects messages whose visibility deadlines have passed, in arrival order and up to the requested batch size. It assigns each a fresh receipt handle, advances its visibility deadline, increments the receive count and returns the claimed rows. Rows locked by another receiver are skipped. Standard queues provide best-effort ordering. Visibility expiry permits redelivery; it does not stop a worker that is still processing an earlier receive. `ApproximateReceiveCount` is the message's **real** receive count (the claim increments it; it is not estimated), and the SQS MD5-of-body and MD5-of-attributes are recomputed so your SDK verifies them byte-for-byte. `DelaySeconds` stamps the message's visibility deadline at send, so a delayed message remains unavailable until that deadline. A **long poll** is a poll loop bounded by `WaitTimeSeconds` (capped at 20s), returning the instant a claim succeeds. A `SendMessageBatch` is a single multi-row insert with faithful per-entry outcomes, and the message body is stored in the queue table. The adapter defaults to a 262144-byte (256 KiB) queue limit; managed SQS requests enforce the declared limit before sending. Native AWS SQS now supports messages up to 1 MiB.
Concurrent receives use atomic row claims and skip rows locked by another receiver. ApproximateReceiveCount is the message's real receive count.
#### Receipt handles & visibility Receiving writes a receipt token to the message row. `DeleteMessage` and `ChangeMessageVisibility` find that row by its token, including after an adapter restart or through another adapter instance. No in-memory receiver or broker lock is required. A delete or visibility change with no matching row returns `ReceiptHandleIsInvalid`. This includes messages already deleted or claimed again under a newer token. Visibility is a timestamp on the row, defaulting to 30 seconds on receive. `ChangeMessageVisibility` can extend it without a broker lock-duration maximum; zero makes the message immediately available to claim again. Retention can delete a message while it is in flight, and a newer claim makes the old token stale.
Receipt handles are stored with messages, so they remain usable after an adapter restart. Visibility deadlines have no broker lock-duration limit.
#### Dead-letter & retention During receive, one database transaction moves messages at or past `maxReceiveCount` from the source table to the dead-letter table and claims the remaining candidates. The move and claim commit together, so an interrupted transaction cannot leave a message deleted from the source without its DLQ copy. The DLQ uses the same queue operations and retention cleanup. Moved messages start with a reset receive count. A background cleanup task deletes messages whose send time is older than the queue's retention period, including messages in flight. Receiving does not change that timestamp. Cleanup reads the stored retention attribute, defaults to four days and clamps it to 60 seconds–14 days. A missing or invalidly short value therefore cannot delete newly sent messages immediately. One worker per database runs each cleanup pass in batches, backs off during database maintenance and isolates queue errors. A circuit breaker and per-batch time limit bound the work.
One transaction moves failed messages to the DLQ and claims eligible messages. A background worker removes messages older than their retention period, clamped to 60 seconds-14 days.
#### FIFO queues For message-group ordering and five-minute send deduplication, see [SQS FIFO](/service-adapters/aws/messaging-streaming/sqs-fifo). #### Limitations △ Where SQS and this backend diverge, read before you adopt * **Throughput is bounded by one PostgreSQL server.** All of an appliance's queues share one PostgreSQL server, so peak throughput is bounded by that one server, and a heavy queue can affect its neighbors. On the Tensor9 round-trip eval the Postgres adapter holds throughput parity with native SQS (about 300 vs 286 ops/s) and a tighter end-to-end tail (p99 140 ms vs SQS's 172 ms), while SQS is faster at the median (p50 15 ms vs 24 ms), results from that moderate-rate Standard-queue workload, not a measured throughput ceiling. This benchmark does not measure FIFO throughput or every hosting option. * **CloudNativePG data lives in-cluster and does not survive a cluster rebuild.** The in-cluster CloudNativePG host keeps queue data inside the appliance cluster, so a full cluster rebuild loses it; the two managed hosts (Cloud SQL Postgres, Azure Flexible Server) keep queue data on a provider-operated server outside the cluster, so it survives a rebuild. All three hosts use the same queue implementation; database placement changes rebuild recovery. * **Stale receipt handles return an error.** `DeleteMessage` and `ChangeMessageVisibility` return `ReceiptHandleIsInvalid` when no row matches the token. * **Retention cleanup runs periodically.** An expired message can remain until the next cleanup pass. Retention is clamped to 60 seconds–14 days, with invalidly short values raised to 60 seconds to avoid deleting newly sent messages. * **Approximate counts are a point-in-time exact count.** `ApproximateNumberOfMessages` and `...NotVisible` are a real count of the visible and not-yet-visible messages in the queue's table, exact at query time, but still Approximate under concurrent traffic; the delayed-count is reported as zero. * **Control-plane calls operate on the apply-time schema.** The database, the catalog, and each per-queue table (and its dead-letter table) are created by the compiler's provisioner; runtime `CreateQueue` / `DeleteQueue` / `SetQueueAttributes` operate on that provisioned schema, and a switch between standard and FIFO is refused as a replace rather than silently mutating semantics. #### Other considerations * **Plan message cutover.** The database, catalog and queue tables start empty. Existing SQS messages are not migrated. Drain the source or coordinate dual writes during the transition. * **Provisioning and ownership.** The adapter provisions and owns its own schema atomically per queue (one database per appliance, a catalog, and one durable table per declared queue, plus its dead-letter table), so a crash never leaves a half-provisioned queue. Each queue is marked with an ownership stamp: the layer never touches a queue it doesn't own (an unstamped or foreign-owned queue detaches rather than deletes), and it refuses to drop a non-empty queue without force. * **Three hosts, one backend, keyless on the managed ones.** The same backend supports CloudNativePG, Cloud SQL Postgres and Azure Flexible Server. On the two managed hosts the connection is keyless (an Entra or Cloud SQL IAM token obtained in-process and presented as the database password, no static secret), and the provider operates the database's durability, backup, and HA while Tensor9 operates the adapter. ## On Azure, OCI, and Private Kubernetes ### Via CloudNativePG | Operation | Area | Support | Depth | Notes | | ----------------------- | -------------- | --------- | ---------- | -------------------------------------------------------------------------------------- | | Dead-letter redrive | Dead-letter | Supported | Most usage | fires automatically once a message passes maxReceiveCount | | Message attributes | Messages | Supported | Common | - | | GetQueueAttributes | Queues | Supported | Most usage | reads queue attributes, including approximate message counts | | GetQueueUrl | Queues | Supported | Most usage | resolves the queue by name | | DelaySeconds | Send / receive | Supported | Common | a delayed message remains hidden until its delay expires | | DeleteMessage | Send / receive | Supported | Common | resolves by receipt handle; a stale handle returns ReceiptHandleIsInvalid | | DeleteMessageBatch | Send / receive | Supported | Common | returns the result for each entry | | ReceiveMessage | Send / receive | Supported | Common | long-poll (WaitTimeSeconds) honored; claims the oldest visible messages | | SendMessage | Send / receive | Supported | Common | supports both SQS protocol formats; MD5 checksums match what your SDK verifies | | SendMessageBatch | Send / receive | Supported | Common | up to 10 messages per call; returns the result for each entry | | ChangeMessageVisibility | Visibility | Supported | Common | resolves by receipt handle; a stale handle is rejected rather than silently succeeding | #### PostgreSQL hosting Tensor9 operates CloudNativePG inside the customer's Kubernetes cluster. Queue data is stored on that cluster's volumes and does not survive a full cluster rebuild. Plan recovery and message cutover before replacing the cluster. Tensor9 operates the queue schema and adapter. Queues start empty; existing SQS messages are not migrated. Drain the source or coordinate dual writes before cutover. #### Queue behavior The adapter uses the same PostgreSQL tables, atomic message claims, stored receipt handles and transactional dead-letter moves described in [PostgreSQL queue behavior](/service-adapters/aws/messaging-streaming/sqs-standard#postgresql-queue-behavior). Receipt handles survive adapter restarts; stale claims return an error. Retention still removes messages in flight. All queues share database capacity, so a busy queue can affect others. The documented Standard-queue benchmark does not establish this host's capacity or FIFO throughput. Delivery is at least once with best-effort ordering. For group ordering and deduplication, see [SQS FIFO](/service-adapters/aws/messaging-streaming/sqs-fifo). ## On Azure ### Via Azure Queue Storage | Operation | Area | Support | Depth | Notes | | ------------------------------------- | -------------- | --------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | Dead-letter redrive | Dead-letter | Partial | Most usage | the application must move failed messages to a separate queue using dequeue\_count | | CreateQueue | Queues | Supported | Most usage | queue operation | | DeleteQueue | Queues | Supported | Most usage | queue operation | | ListQueues | Queues | Supported | Most usage | queue operation | | PurgeQueue | Queues | Supported | Most usage | queue operation | | SetQueueAttributes | Queues | Partial | Full surface | Max stores visibility and retention defaults and applies them to messages; nonzero queue delay and dead-letter routes are rejected | | TagQueue / UntagQueue / ListQueueTags | Queues | Supported | Full surface | logical queue tags in the Max catalog | | Batch operations | Send / receive | Partial | Most usage | no native batching; a batch runs as N round-trips | | DelaySeconds | Send / receive | Supported | Common | maps to send-visibility | | DeleteMessage | Send / receive | Supported | Common | a stale pop\_receipt no-ops just as SQS does | | ReceiveMessage | Send / receive | Supported | Common | queue operation authenticated through workload identity | | SendMessage | Send / receive | Supported | Common | queue operation authenticated through workload identity | | ChangeMessageVisibility | Visibility | Supported | Common | resolves by pop\_receipt, stateless and durable across an adapter restart | #### How it works Tensor9 adds an adapter, a proxy process, to your application pod and sets `AWS_ENDPOINT_URL_SQS` to its loopback address. Your application keeps its `SendMessage` and `ReceiveMessage` calls. The adapter translates them to Queue Storage operations and returns SQS responses, error codes and MD5 checksums. Each declared standard SQS queue becomes a Queue Storage queue in one storage account. Receipt handles and receive counts map to Queue Storage's `pop_receipt` and `dequeue_count`. Each message body is base64-encoded, with attributes included in a JSON envelope when present. The encoded size limit leaves roughly 48 KiB for the payload, and applications must manage dead-letter delivery themselves. FIFO queues are routed to Service Bus.
The application keeps its SQS SDK. The adapter translates its calls to Azure Queue Storage.
#### Architecture The Rust adapter uses Queue Storage's `pop_receipt` to delete messages and change visibility across calls. A handle remains usable after an adapter restart, and instances can scale out without a receiver pool, lock-renewal loop or cleanup worker. The customer's AKS Workload Identity supplies a federated token through the cluster webhook, without a static account key. Microsoft operates Queue Storage's durability, backups and high availability; Tensor9 operates the adapter. Terraform creates one storage account and one queue per declared SQS queue, preserving queue names. `message_text` contains the base64-encoded body and, when supplied, a JSON envelope with `MessageAttributes`. Queue Storage's `pop_receipt`, `dequeue_count` and `time_next_visible` provide the receipt token, receive count and visibility deadline. * **Queue Storage retains message state.** Receipt tokens remain valid across adapter restarts. Runtime operations need no receiver pool, lock-renewal loop or separate retention worker. * **One storage account, one queue per declared SQS queue, reached keylessly.** The path runs on the customer's AKS Workload Identity with no static key; Microsoft operates durability, backup, and HA, and Tensor9 operates the adapter.
Queue Storage stores messages, receipt tokens, receive counts and visibility deadlines. The adapter translates these fields to SQS without retaining durable state.
#### Receiving messages A `ReceiveMessage` is a **bounded long-poll**. Queue Storage has no native long-poll, so the adapter turns `WaitTimeSeconds` (capped at 20, the SQS maximum) into a poll loop that runs once immediately and then sleeps **about 300 ms between empty polls** until the budget elapses; a fixed poll interval, not a latency figure. Each poll pulls up to 10 messages : SQS caps a receive at 10, and although Queue Storage itself would return up to 32 the layer honors the SQS contract. The per-receive **visibility timeout passes straight through** (Queue Storage imposes no visibility-versus-TTL coupling on receive), and SQS's 12-hour maximum sits comfortably under Queue Storage's own 7-day ceiling, so nothing is clamped. Each received message includes `message_id`, `message_text`, `pop_receipt`, `dequeue_count` and `time_next_visible`. The adapter builds the SQS receipt handle from the receipt token and sets `ApproximateReceiveCount` from the dequeue count, which starts at 1 and increases on redelivery. It decodes the body and attributes and recomputes their MD5 checksums. Delivery is at-least-once with best-effort ordering. `DelaySeconds` sets initial invisibility. Use Azure monitoring for measured receive latency and throughput.
A receive is a bounded long-poll that returns Queue Storage's own pop\_receipt and dequeue\_count ; there is no lock to renew. ApproximateReceiveCount is the real dequeue\_count , counted from 1.
#### Receipt handles & visibility The receipt handle contains `queue | message_id | pop_receipt`, base64url-encoded with a `qs1:` prefix. Queue Storage accepts the receipt across connections and processes, so delete and visibility changes still work after an adapter restart. A stale receipt, from a deleted or re-received message, produces a successful no-op on delete or update. A malformed handle or one for another queue returns `ReceiptHandleIsInvalid`. Native Queue Storage sets visibility on individual messages and has no queue-level default. Max stores the logical SQS queue's visibility default and applies it when `ReceiveMessage` omits an override. `ChangeMessageVisibility` maps to `update_message`, which re-stamps `time_next_visible`; a zero-second change surfaces the message for **immediate re-claim**, and SQS's 12-hour maximum sits under Queue Storage's 7-day ceiling , so the full SQS range passes through with **no clamp**. Because settle is by `pop_receipt` and not a broker lock, a consumer that lost its claim to a redelivery finds its `pop_receipt` superseded; the update no-ops rather than corrupting another consumer's claim.
Queue Storage accepts the native pop\_receipt across adapter restarts. SQS's 12-hour visibility fits within Queue Storage's 7-day ceiling.
#### Payload size and dead-letter delivery `message_text` must be safe for XML and UTF-8, so the adapter base64-encodes each body. Encoding expands it by about 4/3; Queue Storage's 64 KiB limit therefore permits roughly 48 KiB of raw payload, less when attributes add overhead. The adapter checks encoded size and returns `InvalidParameterValue` with the size and limit for an oversized send. For larger messages, use another target or store the body in Blob Storage and send its location. Queue Storage does not move messages to a dead-letter queue automatically. The adapter exposes `dequeue_count` as `ApproximateReceiveCount`; your application uses it to decide when to move a message to a separately provisioned `
Base64 encoding reduces the usable payload to roughly 48 KiB. Queue Storage has no automatic dead-letter delivery; the application moves failed messages to a separately provisioned queue.
#### Limitations △ Where SQS and Queue Storage diverge, read before you adopt * **Classic queues only: FIFO is rejected.** Queue Storage has no session, ordering, or dedup analog, so a `.fifo` origin is routed to Service Bus at compile time, and any `.fifo` traffic that still reaches this backend (a pre-declared queue or an out-of-band URL) is rejected with an error on send, receive, create, and purge. There is no message-group ordering and no deduplication here at all. * **The usable payload is roughly 48 KiB.** Base64 encoding expands the body by about 4/3, and attribute overhead also counts toward Queue Storage's 64 KiB encoded limit. Oversized sends return `InvalidParameterValue`. See the payload-size section. * **Your application must move failed messages.** Use `ApproximateReceiveCount` to decide when to copy a message to `
The application calls its existing SQS SDK; the adapter translates those calls to Azure Service Bus operations.
#### Architecture The Rust adapter translates SQS operations to Service Bus Standard over AMQP 1.0. It authenticates with the customer's AKS Workload Identity and the `Azure Service Bus Data Owner` role. This grants access to messages without a static secret; it does not grant permission to create or configure queues. SQS `ReceiveMessage` then `DeleteMessage` are separate API calls: the opaque receipt handle holds the state between them. Service Bus PeekLock works differently: the lock-token is bound to the **receiver link** that fetched it, and only that same receiver can complete, abandon, or renew it. So the adapter runs a **receiver pool**: one long-lived PeekLock receiver per queue (with `prefetch` pinned to `0`, so a message's lock clock never starts before a caller asks for it), a `receipt-handle → in-flight-message` registry, and a background renew loop that keeps each in-flight lock alive under your requested visibility window against Service Bus's 5-minute lock cap. Senders share the client; each received message is settled on the very link that fetched it. Service Bus entity CRUD (creating a queue, setting its lock duration, its DLQ, its retention) is **control-plane** (ARM), and the keyless data-plane role grants data access, not namespace entity management. The backend uses **pre-provisioned entities**: the compiler provisions the namespace and queue at apply-time (a 5-minute lock, a redelivery limit from your redrive policy, and DLQ auto-forwarding), and `CreateQueue` merely verifies the queue is reachable by opening a sender. Microsoft operates Service Bus's durability, backup, and HA; Tensor9 operates the adapter. * **Each message uses its original receiver until settlement.** The adapter records receipt handles with the Service Bus receiver that obtained each lock. Prefetch is zero, so a lock starts only when a consumer requests a message. * **Entities are provisioned at apply-time, never by the data plane.** A 5-minute lock, a redelivery limit, and DLQ forwarding are compiled from your queue's declared attributes; the adapter never needs, and never holds, a control-plane credential.
The adapter retains each receiving connection and receipt handle until the message is deleted or its lock expires. Terraform provisions the queue's lock duration, redelivery limit and dead-letter forwarding.
#### Receiving messages `ReceiveMessage` uses PeekLock to receive and lock messages. `MaxNumberOfMessages` is clamped to 1–10 and `WaitTimeSeconds` to 20 seconds, then passed to Service Bus as its maximum wait. A standard queue needs no session-accept step, so an empty queue returns within that wait. For each message, the adapter creates a receipt handle and records which receiver holds the lock. Delete and visibility changes use that same receiver. Standard queues allow duplicates and provide best-effort ordering. `ApproximateReceiveCount` uses Service Bus's `delivery_count`, starting at 1 and increasing on each redelivery; this count also determines when a failing message is dead-lettered. The adapter recomputes MD5 checksums and reads `SentTimestamp` from the enqueue time. `DelaySeconds` schedules delivery up to 900 seconds; larger values return `InvalidParameterValue`. Batch sends process entries individually and return each entry's result, including separately scheduled delays.
A receive is a PeekLock: the receiver locks up to ten messages within your long-poll wait, and the adapter assigns a receipt handle held on the same link. ApproximateReceiveCount is the real Service Bus delivery\_count .
#### Receipt handles & visibility A receipt handle has the form `sb1 | queue | lock-token`. The adapter records its Service Bus receiver because only that receiver can complete, abandon or renew the lock. This state is held between `ReceiveMessage` and a later delete or visibility change. **Receipt handles expire on adapter restart.** Restarting drops the client, receivers and registry. A later delete or visibility change with an old handle returns `ReceiptHandleIsInvalid`. The message remains in Service Bus and becomes available again when its lock expires, within 5 minutes. **A visibility request cannot exceed 5 minutes.** Larger values return `InvalidParameterValue` because Service Bus caps lock duration at 5 minutes. A positive `ChangeMessageVisibility` renews the lock; zero abandons the message for immediate redelivery. The background renewal loop maintains the lock during the requested window.
Receipt handles depend on the live Service Bus receiver and become invalid after an adapter restart. A requested visibility timeout above 5 minutes returns an error.
#### Dead-letter & retention Service Bus dead-letters a message when its delivery count reaches the queue's limit, set from `maxReceiveCount`. Because the adapter cannot receive from Service Bus's internal dead-letter subqueue, Terraform configures automatic forwarding to your declared dead-letter queue (DLQ). Expired messages are also dead-lettered and remain available there for inspection or recovery. Terraform configures retention, lock duration and dead-letter forwarding through Azure Resource Manager (ARM) when creating the queue. The native messaging role cannot read Azure Resource Manager settings. The Max adapter answers configuration reads from its declared queue catalog; live message counts remain unavailable from this transport. Broker messages are durable, while receiver links, active locks and receipt-handle mappings belong to the adapter process.
Service Bus forwards failed messages to your declared DLQ after maxReceiveCount deliveries. Terraform configures retention and queue settings; runtime message permissions do not allow the adapter to read them.
#### Limitations △ Where SQS (standard) and Service Bus diverge, read before you adopt * **The visibility timeout is capped at 5 minutes.** A visibility timeout maps to the PeekLock lock, whose ceiling is Service Bus's 5-minute lock-duration cap; a requested value above 5 minutes is rejected with an error ( InvalidParameterValue ) rather than being silently clamped (a clamp would risk double-processing before your window elapsed). Extension via ChangeMessageVisibility renews the lock, so long-held work is supported by re-extending, not by one long timeout. * **Receipt handles expire on adapter restart.** A later delete or visibility change returns `ReceiptHandleIsInvalid`. The message becomes available again after its Service Bus lock expires, within 5 minutes. Cosmos DB and PostgreSQL handles differ: those handles remain usable after an adapter restart. * **At-least-once, best-effort order, and no deduplication.** This is the SQS standard-queue contract: order is not guaranteed and duplicates are possible, and there is deliberately no dedup. Strict per-group order and duplicate detection are the FIFO contract: declare a `.fifo` queue, which is served on Service Bus sessions by a separate path (documented in the FIFO explainer). * **Live counts are unavailable through the messaging transport.** The Max queue catalog supplies declared retention, visibility and DLQ configuration. `ApproximateNumberOfMessages` is omitted; use Azure monitoring for live queue counts and requests. * **Separate logical queue management from broker provisioning.** The Max catalog handles queue listings, tags and supported attribute edits. Creating a logical queue checks that its provisioned Service Bus entity is reachable; deleting the logical queue does not delete that entity. Explicit retention changes, nonzero queue delay and new dead-letter routes require broker configuration and are rejected by the messaging backend. * **PurgeQueue is bounded and racy.** A purge is a bounded receive-and-complete drain loop; a concurrent producer can enqueue mid-drain and only currently visible messages are drained. This differs from native SQS PurgeQueue , which also removes in-flight messages. Use Azure monitoring to measure latency and throughput for your workload; this adaptation does not promise specific performance numbers. #### Other considerations * **Nothing in flight migrates.** The Service Bus namespace and its queues come up empty at deploy time, so messages still sitting in an SQS queue on AWS are not moved across; cut over at a drain point, or dual-write until the SQS side is drained. * **Microsoft operates Service Bus; Tensor9 operates the adapter.** Microsoft manages queue durability, replication and availability. Include the adapter in your application's operational monitoring. * **Check visibility and restart handling before cutover.** Consumers must account for the 5-minute visibility limit and receipt handles becoming invalid after an adapter restart. Uncompleted messages remain in Service Bus and can be delivered again after their locks expire; message retention and dead-letter policies still apply. * **Estimate Service Bus costs from operations and capacity.** Standard bills per messaging operation; Premium bills per provisioned messaging unit. Include receives, renewals and deletes in the estimate. ### Via Azure Cosmos DB (queue) | Operation | Area | Support | Depth | Notes | | ----------------------------------------------------- | -------------- | --------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Dead-letter redrive | Dead-letter | Supported | Most usage | at claim time a message past maxReceiveCount moves to the declared DLQ queue via a retried copy-then-delete move; a retry can produce a duplicate in the DLQ | | CreateQueue / DeleteQueue / SetQueueAttributes / tags | Queues | Partial | Full surface | Max manages logical queues on provisioned containers, tags and supported defaults. Terraform owns the account, database and containers; nonzero queue delay and new dead-letter routes are rejected | | GetQueueAttributes (approximate counts) | Queues | Partial | Full surface | approximate depth, cached \~5 s; can briefly include documents awaiting TTL expiry | | ListQueues | Queues | Supported | Full surface | exact: the declared queue set | | DelaySeconds | Send / receive | Supported | Common | per-message delay ranges from zero to a maximum of 900 seconds; larger values return InvalidParameterValue | | DeleteMessage | Send / receive | Supported | Common | deletes by receipt handle, which is stateless, so a stale handle no-ops just as SQS does | | ReceiveMessage | Send / receive | Supported | Common | messages are claimed in arrival order, giving best-effort order and at-least-once without a fairness guarantee; ApproximateReceiveCount is the message's real receive count | | SendMessage | Send / receive | Supported | Common | each message is a Cosmos document; MD5 checksums recomputed for your SDK | | SendMessageBatch | Send / receive | Supported | Common | per-entry writes with a result for each entry | | ChangeMessageVisibility | Visibility | Supported | Common | extends the message's visibility with no cap (there is no broker lock ceiling); a stale handle is rejected rather than silently succeeding | #### How it works Tensor9 adds an adapter, a proxy process, to your application pod and sets `AWS_ENDPOINT_URL_SQS` to its loopback address. Your application keeps its `SendMessage` and `ReceiveMessage` calls. The adapter implements them using Cosmos DB and returns SQS responses, error codes and MD5 checksums. Each queue has a Cosmos DB container, with one document per message. The adapter uses these documents for sending, receiving, deletion, delay, visibility, dead-letter delivery and counts. Standard queues claim messages in arrival order, with best-effort ordering under concurrent traffic.
The application keeps its SQS SDK. The adapter stores and reads messages in Azure Cosmos DB.
#### Architecture The Rust adapter stores durable state in Cosmos DB, so instances can restart or scale out without sharing an in-memory lock table. It authenticates through the customer's AKS Workload Identity without a static secret. Microsoft operates Cosmos DB's durability, backups and high availability; Tensor9 operates the adapter. On the Cosmos side, the compiler provisions one serverless Cosmos account and one database per appliance , and inside it **one container per declared queue** (the container id is the queue name). Every message is a document that holds the SQS body, its attributes, its receive count, and a visibility timestamp. A **Standard** queue stores its messages durably and claims eligible messages in arrival order. Concurrent claims do not establish a fairness or no-starvation guarantee. Retention rides Cosmos's **native per-item TTL**, so an expired message is reclaimed by Cosmos itself. * **Cosmos DB coordinates message claims.** Adapter instances share message and claim records in the database, so an adapter restart does not erase them.
A queue is one Cosmos container and each message is a document; a Standard queue stores messages durably and claims eligible messages with best-effort ordering.
#### Receiving messages Receiving atomically claims the oldest visible message, hides it from other receivers and increments its receive count. If another receiver claims the candidate first, the adapter moves to the next one. Each successful conditional write has one owner; visibility expiry still permits redelivery. Standard queues use **at-least-once delivery with best-effort ordering**. `ApproximateReceiveCount` is the **real** receive count (incremented on each claim, not estimated), and the SQS MD5-of-body and MD5-of-attributes are recomputed so your SDK verifies them byte-for-byte. Standard queues keep a delayed message invisible for its requested `DelaySeconds`, up to a maximum of 900 seconds. An omitted value means zero; larger values return `InvalidParameterValue`. A `SendMessageBatch` runs as per-entry writes with faithful per-entry outcomes.
A receive reads the oldest visible message and claims it for exactly one consumer; if another consumer claims it first, this receive moves to the next candidate. ApproximateReceiveCount is the real receive count, incremented on each claim, never estimated.
#### Receipt handles & visibility SQS hands your consumer a **receipt handle** to delete or extend a message. Here that handle is a token for claim state stored in Cosmos DB. Because the adapter keeps no in-memory lock table, a current handle resolves the same way before and after a restart: `DeleteMessage` and `ChangeMessageVisibility` keep working. A stale handle (the message was already deleted, or a newer claim superseded this one) is a **no-op on delete**, exactly as SQS's own stale handle is; a cross-queue or unparseable handle is rejected as `ReceiptHandleIsInvalid`. `ChangeMessageVisibility` updates the stored visibility time without a broker lock-duration maximum. Zero makes the message immediately available to claim again. Retention can expire a message while it is in flight; extending visibility does not extend its lifetime. A stale handle is rejected, allowing the consumer to detect that it no longer owns the claim. Visibility expiry does not stop a worker from continuing to process an earlier receive.
Receipt handles remain usable after an adapter restart. Visibility is stored in Cosmos DB and has no broker lock-duration limit.
#### FIFO queues For message-group ordering and five-minute send deduplication, see [SQS FIFO](/service-adapters/aws/messaging-streaming/sqs-fifo). #### Dead-letter queues A message received more than `maxReceiveCount` times is moved to the declared dead-letter queue. If the adapter crashes during the move, retry ensures it reaches the DLQ before removal from the source. A retry can produce a duplicate in the DLQ; consumers there must handle at-least-once delivery.
The adapter retries interrupted dead-letter moves. Delivery to the DLQ is at-least-once, so a crash can cause a duplicate.
#### Limitations △ Where SQS and Cosmos diverge, read before you adopt * **Approximate counts can lag by about 5 seconds.** The adapter caches counts briefly, so recent sends, settlements and expirations may not be reflected immediately. Use Azure monitoring to observe counts after deployment. * **Dead-letter delivery can produce duplicates.** Retry completes a move interrupted by an adapter crash without losing the message, but can deliver it to the DLQ more than once. * **Queue capacity is bounded by the serverless container count.** All of an appliance's queues share one serverless Cosmos account, which caps at about 500 containers, so roughly 499 queues per appliance (one container per queue). Beyond that the build stops with a clear error rather than half-provisioning. The account is **serverless by design**, a fit for idle-heavy queue fleets. * **Single region.** The account is single-region (the appliance's region); there is no geo-replica. * **Cosmos DB removes expired messages.** Per-item time to live (TTL) is enforced by background cleanup. Expiry can occur while a consumer is processing the message. * **Per-message delay.** Standard queues honor `DelaySeconds` up to a maximum of 900 seconds; larger values return `InvalidParameterValue`. * **Separate logical queue management from container provisioning.** Max manages logical queues on provisioned containers, listings, tags and supported defaults, including retention. Terraform owns the account, database and containers; deleting a logical queue does not delete its container. Nonzero queue-level delay and new dead-letter routes are rejected. #### Other considerations * **Data migration.** The Cosmos account, database, and per-queue containers are provisioned empty at apply-time. In-flight SQS messages are not migrated; drain the source or coordinate dual writes before cutover. * **Operations and ownership.** The adapter provisions the Cosmos deployment itself (one serverless account, one database per appliance, and one container per declared queue), all derived from your declared queues; the adapter is injected alongside the application. Microsoft operates Cosmos's durability, backup, and HA; Tensor9 operates the adapter. What remains operational for the deployment is the surrounding platform: the Azure subscription, cluster patching, and monitoring. * **Monitor database usage.** Use Azure monitoring to track Cosmos DB request units and latency; queue counts are cached for about 5 seconds. * **Retention is native, whole-second Cosmos TTL.** A message's remaining lifetime is Cosmos's native per-item TTL set to the remaining whole-second budget (floored at one second, so Cosmos reclaims at or after the message is hidden, never before it), with no background cleanup of its own. ### Via PostgreSQL Flexible Server | Operation | Area | Support | Depth | Notes | | ----------------------- | -------------- | --------- | ---------- | ----------------------------------------------------------------------------------------------------------------------- | | Dead-letter redrive | Dead-letter | Supported | Most usage | fires automatically once a message passes maxReceiveCount | | Message attributes | Messages | Supported | Common | - | | GetQueueAttributes | Queues | Supported | Most usage | reads queue attributes, including approximate message counts | | GetQueueUrl | Queues | Supported | Most usage | resolves the queue by name | | DelaySeconds | Send / receive | Supported | Common | a delayed message remains hidden until its delay expires | | DeleteMessage | Send / receive | Supported | Common | resolves by receipt handle; a stale handle returns ReceiptHandleIsInvalid | | DeleteMessageBatch | Send / receive | Supported | Common | returns the result for each entry | | ReceiveMessage | Send / receive | Supported | Common | long-poll (WaitTimeSeconds) honored; claims the oldest visible messages | | SendMessage | Send / receive | Supported | Common | supports both SQS protocol formats; MD5 checksums match what your SDK verifies, identical to the portable Postgres tier | | SendMessageBatch | Send / receive | Supported | Common | up to 10 messages per call; returns the result for each entry | | ChangeMessageVisibility | Visibility | Supported | Common | resolves by receipt handle; a stale handle is rejected rather than silently succeeding | #### PostgreSQL hosting Microsoft operates PostgreSQL Flexible Server, including zone-redundant HA and point-in-time recovery backups. The adapter uses short-lived Microsoft Entra tokens as database passwords. Queue data stays outside the customer's Kubernetes cluster and survives its rebuild. One server and database hold all queues for the deployment, sharing capacity and maintenance; the default server size is fixed because SQS supplies no source instance size. Tensor9 operates the queue schema and adapter. Queues start empty; existing SQS messages are not migrated. Drain the source or coordinate dual writes before cutover. #### Queue behavior The adapter uses the same PostgreSQL tables, atomic message claims, stored receipt handles and transactional dead-letter moves described in [PostgreSQL queue behavior](/service-adapters/aws/messaging-streaming/sqs-standard#postgresql-queue-behavior). Receipt handles survive adapter restarts; stale claims return an error. Retention still removes messages in flight. All queues share database capacity, so a busy queue can affect others. The documented Standard-queue benchmark does not establish this host's capacity or FIFO throughput. Delivery is at least once with best-effort ordering. For group ordering and deduplication, see [SQS FIFO](/service-adapters/aws/messaging-streaming/sqs-fifo). ## On OCI ### Via OCI Queue | Operation | Area | Support | Depth | Notes | | ----------------------- | -------------- | --------- | ------------ | ------------------------------------------------------------------------------------------- | | Dead-letter | Dead-letter | Partial | Most usage | redrive maps to OCI Queue's delivery-count dead-letter (count-based) | | Max message size | Queues | Supported | Full surface | 128 KB, OCI Queue's message ceiling | | Message retention | Queues | Supported | Full surface | the SQS 4-day default is emitted explicitly; retention runs up to OCI Queue's 7-day maximum | | Visibility timeout | Queues | Supported | Full surface | OCI Queue's 30 s default, passed through and honored | | DeleteMessage | Send / receive | Supported | Common | served onto OCI Queue's DeleteMessage | | Long-polling | Send / receive | Supported | Most usage | native long-poll on GetMessages | | ReceiveMessage | Send / receive | Supported | Common | served onto OCI Queue's GetMessages | | SendMessage | Send / receive | Supported | Common | served onto OCI Queue's PutMessages; MD5 checksums recomputed for your SDK | | ChangeMessageVisibility | Visibility | Supported | Common | resolves by receipt handle; the 30 s visibility default is honored and extended per message | #### How it works Tensor9 adds an adapter, a proxy process, to your application pod in OCI and sets `AWS_ENDPOINT_URL_SQS` to its loopback address. Your application keeps its `SendMessage` and `ReceiveMessage` calls. The adapter translates them to OCI Queue operations and returns SQS responses, error codes and MD5 checksums. Each declared standard SQS queue becomes an OCI queue in the customer's compartment. `SendMessage` puts a message; `ReceiveMessage` gets one with a receipt; `DeleteMessage` deletes it using that receipt. OCI Queue stores messages, receipts, delivery counts and visibility deadlines, so the adapter holds no durable state. FIFO queues require a different target because OCI Queue does not support group ordering or deduplication.
The application keeps its SQS SDK. The adapter translates calls to OCI Queue.
#### Architecture The Rust adapter uses OCI Queue receipts across calls and processes, so receipt handles remain usable after an adapter restart. Adapter instances can scale out without coordinating durable state. Authentication uses the customer's OCI workload identity without a static credential. Oracle operates queue durability, backups, replication and high availability; Tensor9 operates the adapter. Terraform creates one OCI queue per declared SQS queue in the customer's compartment, preserving its name. Queue visibility uses the declared SQS default; both services default to 30 seconds. Retention maps to OCI Queue's retention, capped at 7 days. `maxReceiveCount` sets the delivery-count threshold. OCI Queue manages these settings and tracks queued and in-flight messages.
Each SQS queue maps to an OCI queue in the customer's compartment. OCI Queue stores receipt tokens, receive counts and visibility deadlines.
#### Receiving messages A `ReceiveMessage` is a **bounded long-poll**. `WaitTimeSeconds` (capped at 20, the SQS maximum) maps to OCI Queue's **get long-poll timeout**, which itself allows up to 30 seconds, so the full SQS wait range passes through with **no clamp**. Each get pulls up to 10 messages : SQS caps a receive at 10, and although OCI Queue itself would return up to 20 the adapter honors the SQS contract. The per-receive **visibility timeout passes straight through** to OCI Queue's per-receive visibility, and OCI Queue applies it when it hands the message out. The OCI receipt becomes the SQS receipt handle. `ApproximateReceiveCount` uses OCI Queue's delivery count, starting at 1 and increasing on redelivery. The adapter reconstructs the body and attributes and recomputes MD5 checksums for SDK verification. Delivery is at-least-once with best-effort ordering. Single sends use OCI put; batch sends use a multi-message put with a result for each entry. Deletion uses the receipt. Use OCI monitoring for measured latency and throughput.
A receive is a bounded long-poll that returns OCI Queue's own receipt and delivery count; there is no lock to renew. ApproximateReceiveCount is the real delivery count, counted from 1.
#### Receipt handles & visibility The receipt handle contains OCI Queue's receipt token. Delete and visibility updates use this token across calls, connections and adapter restarts. A receipt superseded by another receive, or belonging to an already deleted message, produces a successful no-op. Malformed handles and handles for another queue return `ReceiptHandleIsInvalid`. The **visibility timeout maps to OCI Queue's per-message visibility**. The queue's default is provisioned on the OCI queue, and OCI Queue's 30-second default equals the SQS default , so an unset queue matches SQS exactly. The per-receive `VisibilityTimeout` rides the get, and `ChangeMessageVisibility` maps to **update**, which re-stamps the message's visibility; a zero-second change surfaces the message for **immediate re-claim**, and SQS's 12-hour maximum sits at OCI Queue's own **12-hour ceiling**, so the full SQS range passes through with **no clamp**. Because deletion and visibility changes use the native `receipt`, a consumer that lost its claim to a redelivery finds its `receipt` superseded, and the update no-ops rather than corrupting another consumer's claim.
OCI Queue stores delivery state and accepts a current receipt across adapter restarts. The 30-second visibility default and 12-hour maximum match SQS.
#### Dead-letter & retention `maxReceiveCount` sets the queue's delivery-count threshold. When the count exceeds it, OCI Queue moves the message to its built-in dead-letter queue. The adapter does not copy or delete messages to perform that move. The threshold is preserved, but the destination is always the built-in dead-letter queue; an arbitrary SQS queue name or ARN cannot select a different destination. During Terraform provisioning, Tensor9 explicitly sets the four-day retention default (`345600` seconds) when no value is declared. A declared value above OCI's seven-day maximum (`604800` seconds) is capped at seven days with a warning. A queue declared with SQS's 14-day retention therefore expires messages a week earlier. This is a provisioning conversion; it does not describe a runtime `SetQueueAttributes` request.
OCI Queue moves messages to its built-in dead-letter queue when their delivery count exceeds maxReceiveCount. Terraform provisioning caps retention at 7 days with a warning.
#### Limitations △ Where SQS and OCI Queue diverge, read before you adopt * **Classic queues only; FIFO is rejected with an error.** OCI Queue has no ordering, session, or deduplication analog, so a `.fifo` origin is routed to an ordering-capable backend at compile time, and any `.fifo` traffic that still reaches this backend (a pre-declared queue or an out-of-band URL) is rejected with an error on send, receive, create, and purge. There is no message-group ordering and no deduplication here at all. * **128 KB maximum message, smaller than SQS's 1 MiB.** OCI Queue caps a message at `131072` bytes, against SQS's 1 MiB, so an oversize send is rejected with `InvalidParameterValue` (naming the size and the limit), never silently truncated. If your messages routinely exceed 128 KB, shrink the payload, or use the claim-check pattern (store the body in OCI Object Storage and send a pointer). * **Retention tops out at 7 days, shorter than SQS's 14.** OCI Queue's retention is set from the SQS retention with the 4-day default (`345600`) written out explicitly, and OCI Queue's 7-day maximum (`604800`) caps a longer setting; a message held to SQS's 14-day retention ages out up to a week earlier, while within 7 days the mapping is exact. See the dead-letter and retention section. * **Dead-letter is delivery-count based.** The SQS redrive `maxReceiveCount` maps directly to OCI Queue's delivery-count threshold and OCI Queue moves the message to its own built-in dead-letter queue natively; the count travels exactly, but the target is OCI Queue's built-in per-queue dead-letter rather than an arbitrary named queue or ARN. * **Queue-level delay is not preserved.** During Terraform provisioning, a positive `delay_seconds` is dropped with a warning because OCI Queue has no corresponding setting. Review delayed-delivery requirements before choosing this target. * **Batch operations use OCI Queue batches.** `SendMessageBatch` and `DeleteMessageBatch` use multi-message put and delete operations with results for each entry. `ApproximateNumberOfMessages` and `ApproximateNumberOfMessagesNotVisible` use OCI Queue's visible and in-flight statistics. * **Control-plane and provisioning.** Each declared SQS queue is provisioned as one OCI queue in the customer's compartment at apply-time (the queue create is itself keyless); `ListQueues` answers with the declared set, and control operations that would reconfigure a queue out from under the declared model return a real error rather than doing the wrong thing. * **Single managed queue service; durability is Oracle's.** The data-plane path reaches OCI Queue keylessly via OCI workload identity; Oracle operates OCI Queue's durability, backup, replication, and HA, and Tensor9 operates the adapter. #### Other considerations * **In-flight messages don't migrate.** The OCI queue is provisioned empty at apply-time, so anything still sitting in SQS stays on AWS. Drain the SQS queue at the cutover point, or dual-write to both until the SQS side is empty. * **Check the retention and size limits before cutover.** Queue names, visibility and redrive thresholds map to OCI settings. Provisioning caps retention above 7 days with a warning, and messages above 128 KB are rejected; review queues using SQS's 14-day retention or messages above 128 KB. * **Estimate cost from OCI requests and message volume.** Include the workload's send, receive and delete rates when estimating target costs. [Service Catalog](/service-adapters/catalog).