Before running a
tensor9 command, install the CLI, set T9_API_KEY, and verify your customer account. Online commands are authenticated and their adapter detail is limited to mappings your account is entitled to use.General trade-offs
Classic and FIFO are separate origins. Classic provides at-least-once delivery with best-effort ordering. FIFO orders messages within eachMessageGroupId and suppresses duplicate sends within the supported deduplication window. Neither contract makes application side effects exactly once. A worker can finish a payment and crash before deleting its message.
An authored profile describes the intended mapping and its limits. It does not establish that every design is selectable in the installed release, deployed in this install, or measured at the workload’s scale. Confirm the origin, target, configuration and installed runtime before selection. A native cloud product, an authored card and a supported runtime are different facts. Selecting a backend does not move an existing queue’s backlog.
Decide which behavior matters
Answer these questions before comparing prices:- Must events remain ordered within a customer, account or transaction? How much traffic belongs to the busiest group?
- How many body, attribute and transport-envelope bytes does a message actually use?
- How long does a claim remain unsettled, including work waiting inside the consumer?
- Does the workload need delayed first delivery, visibility extensions, durable receipt handles or receive-attempt replay?
- Does a batch need multiple messages from one group? What happens when members settle or expire at different times?
- Must a dead-letter move be atomic, and can source and destination share the required message transaction?
- How much backlog must survive an outage? Which team restores it and reconciles completed business work?
- How many queue incarnations will be created over the operating horizon, including failed or uncertain creates?
Assign operating responsibility
A separate logical database and login isolate data and permissions. They still share CPU, storage, IOPS, WAL and connection limits with other databases on the same server. Dedicated physical server capacity is a separate choice. The shared control store is not an implicit message store for a new FIFO design.
Google Cloud
Pub/Sub or Cloud SQL PostgreSQL
The Firestore, Spanner and SQL-assisted alternatives are distinct designs with explicit resources. Their appearance here does not add a selectable backend or change a running queue automatically.
Short jobs in Google Cloud
An email worker that completes within a minute and uses stable job IDs can compare native Pub/Sub Classic with direct Cloud SQL. Pub/Sub avoids a dedicated SQL message database; the persistent shared control PostgreSQL allocation remains. Pub/Sub’s cost depends on publication/delivery bytes, attributes, envelope, billing units, redeliveries and subscriptions, rather than a simple one-to-one count of SQS API calls. Pub/Sub queue visibility is 10–600 seconds; per-message visibility also accepts zero for release. Receipts are acknowledgement IDs for a particular delivery on the selected subscription. Settlement and visibility changes use the subscription and ID rather than resolving the original stream. Restart interrupts local streaming/buffer ownership; graceful retirement can release still-buffered work, while already handed-off deliveries are outside that drain. Stream closure does not by itself establish token invalidity, and the mapping provides no qualified SQS-style durable-receipt guarantee across restart. Deadline expiry and redelivery can make an earlier receipt ineffective; a successful acknowledgement after expiry does not prove no later redelivery. Use the current delivery’s receipt and idempotent business effects. Dead-letter forwarding uses an approximate delivery-attempt threshold, requires the correct permissions and must lead to a destination operators can inspect. A topic alone is not an incident-response workflow. Direct PostgreSQL stores visible/delayed times and receipts durably. It supports Classic delayed jobs and FIFO groups, but the direct FIFO engine permits only one message in flight per group. If a group takesT seconds from receive to settlement, useful completion is bounded by roughly 1/T. A larger receive can collect heads from multiple groups; it does not produce a ten-message pipeline inside one group.
Full bodies and wakeups have different failure behavior
In the full-body design, Send commits SQL body, group sequence, dedup result and publication intent. The subscriber validates the broker copy against the existing SQL message and durably records observation before first SQS readiness. A broker outage can therefore block first delivery and consume retention time. Acknowledging the broker copy does not delete the SQL message. Duplicate or late publications cannot create new logical messages. Pub/Sub’s 1 MB/s ordering-key publish limit applies to body, attributes and transport-envelope bytes in this full-body path. More consumers do not remove it. In wakeup mode, the broker carries small hints; SQL scans can discover eligible messages without a hint. The database remains the payload and throughput authority. A notification-byte limit is not a measured payload completion rate. Firestore uses transactionally committed manifests and binary chunks, avoiding the per-document body limit without adding an implicit object bucket. Spanner uses serializable transactions and distributed group keys. In both, candidate queries find work; a transaction owns the claim. Their ordered-batch design, also used by SQL-assisted FIFO transports, is distinct from direct PostgreSQL’s one-head mechanism. Conservative redelivery waits until all unsettled batch members settle or expire. Modified receive attempts require a new attempt; they do not claim unrestricted AWS batch/replay equivalence.Try redelivery and idempotency
Use a disposable queue on the exact selected release and resource configuration. Keep the source queue and production consumers out of the experiment.- Record origin type, backend, endpoint, queue incarnation, capacity and authentication. Inspect the declared settings and native resource binding.
- Send a known job ID and preserve the original response. Receive it, commit one durable application effect and deliberately omit deletion.
- Let visibility expire. Receive again and reconcile the second delivery with the existing completion record; verify that the application does not repeat the business effect.
- Test adapter restart with an outstanding receipt under that backend’s rules. For FIFO, include a blocked head, another group, duplicate sends and partially settled batches.
- Exercise the supported poison/retention path and reconcile every test identity. An empty receive or lower count is not proof of completion or cleanup.
- Retire only owned test queues and native resources through their lifecycle owner. Retain unresolved outcomes and original request identities.
Microsoft Azure
Service Bus: native sessions or SQL authority
Standard shares namespace capacity. Premium reserves messaging units with a capacity floor; a messaging unit is not a fixed messages-per-second multiplier. Check actual entity size, sessions, duplicate detection and configuration. Buying Premium does not remove native receipt or ordering limits. Native receipts belong to receiver links. Visibility is limited to five minutes, and restart or lock loss can leave settlement uncertain. FIFO sessions serialize groups, but receiver slots are bounded and a stalled head occupies a slot. Native duplicate detection does not reproduce the original SQS send identifiers, synchronous send sequence or durableReceiveRequestAttemptId replay. More groups can help aggregate concurrency; no unconditional fairness is promised while all slots remain unsettled.
Max logical creation allocates a fresh, exclusively owned preprovisioned entity. Retirement retains allocation history and never reuses that physical entity for a replacement incarnation. Inventory exhaustion refuses a create. Size inventory for cumulative churn over an operating horizon, including uncertain births, rather than peak active queues alone. Provisioning and native settings require explicit resource authority.
The SQL-authority design is different: a dedicated SQS message database stores full recoverable bodies and user state; Service Bus carries small wakeups. A link restart does not release a SQL claim, and scans recover lost notifications. Conservative batch/replay restrictions still apply. Direct PostgreSQL is the simpler comparison when broker integration does not justify the extra transport and charge. A dedicated logical database does not imply a dedicated physical server.
Cosmos: choose deduplication scope before capacity
Serverless suits idle-heavy consumption; manual provisioned suits steady load; autoscale suits varying provisioned demand. They share transaction, size, hot-partition and retained-storage constraints. The selected profile’s 256-KB message admission is distinct from larger native document/transaction limits; those native limits do not silently raise accepted SQS message size. Runtime capacity changes are explicit resource actions. Serverless-to-provisioned conversion affects the account and is irreversible. Queue-wide FIFO deduplication uses one logical partition for all groups, messages, markers and attempts. Explicit MessageGroup scope distributes independent groups but allows the same dedup ID in two groups. It must not silently replace queue-wide suppression. The 20-GB logical-partition storage ceiling applies to the whole queue in Queue scope and to the busiest group in MessageGroup scope, including payload, index overhead, markers, attempts, terminal state and cleanup lag. More RU does not increase that storage limit. Queue-scope attempt replay applies to unchanged claims; modified claims require a new attempt. Group-partitioned FIFO rejects explicit receive-attempt IDs and receives one group per call. Cross-partition/store atomic dead-letter transfer is unsupported. Purge must freeze every registered group before opening a new generation; interrupted lifecycle work can reduce availability. The default shared serverless Classic arrangement uses one database and a container per queue. The often quoted roughly 499 queues assumes an otherwise unused 500-total-databases-and-containers allowance. Actual account quota and existing resources determine spare headroom; manual/autoscale capacity does not automatically remove that resource-count constraint.Queue Storage: small Classic messages and current receipts
The 64-KiB native limit applies to the complete encoded message. Base64 alone permits at most 48 KiB raw before envelope/attributes. There is no implicit Blob payload mode, FIFO or native dead-letter transfer; poison routing is application-owned. An unchanged current pop receipt supports Receive→Delete across adapter restart. A visibility update rotates the native token, while SQS returns no new handle to the application. Preserving that handle requires qualified retained alias authority across the supported replica/restart scope. The native design does not specify that mechanism; visibility updates and post-update settlement are conditional, with refusal before effects required when the mapping is unqualified. Do not assume a selected Table/SQL alias store or stateless arbitrary-replica settlement. Choose durable claim-state storage when extensions are required.PostgreSQL on CloudNativePG
CloudNativePG retains the direct PostgreSQL queue mechanism inside the application cluster. Flexible Server keeps message data outside AKS and survives replacement of that cluster; its own failover/restore behavior still depends on the chosen database configuration. CloudNativePG needs an explicit data recovery or drained cutover before full cluster replacement. For both, atomic dead-letter transfer requires source and destination in the same supported SQS-owned message database transaction. A shared cloud, server or control log does not make separate databases atomic. No other service’s tables supply that transaction.Compare total cost
Use generated SQS costs with the scenario’s assumptions, then add resources outside its stated scope. A request-rate curve is not the observed workload or a throughput guarantee.
Count requests are a separate workload. PostgreSQL counts scan the message population even when one field is requested; frequent polling over a large backlog competes for pool and I/O capacity. Metadata-only reads do not require that scan. Pure Pub/Sub lacks an SQS count authority; unavailable requested counts must remain explicit unsupported results, not zero. Native monitoring backlog has its own timing and definition; it is not interchangeable with SQS visible, in-flight and initially delayed availability counts.
Unknown body/attribute/envelope sizes, hot-group skew, retained backlog or index overhead remain unknown. Do not substitute a default payload or an old benchmark’s missing size. Record successful sends, delivery attempts, deletes and durable application completions separately. Purge, expiry and dead-letter transfer can reduce queue depth without finishing a job.