Google Cloud Pub/Sub vs Amazon SQS

Message queues are great technology when you need to send and receive messages between different applications, implementing asynchronous worklflows, stream data from processes and various devices, processing jobs or building up that fault tolerance.

It was kind of hard to find a full independent resource on the differences between those two technologies so here is my attempt of noting those differences:

Google's Cloud Pub/Sub combines into 1 global service:

• message queuing
• push and pull based message delivery
• high volume streaming message delivery
• Supports fan-in and fan-out

Amazon SQS operations center around message queue that you create:

• client applications pull messages from the queue

Global vs Regional

Global message routing is to simplify multi-region systems. With AWS SQS queing you need to build it and manage it on your own.

Fan-in

Multiple message sources can target a single topic. Both support this one.

Fan-Out

Multiple subscribers can consume a single message

Within AWS to implement Fan-out system you need to combine SQS with additional service: SNS (simple notification system), while Cloud Pub/Sub natively supports fan-out.

Message delivery guarantees

Amazon SQS offers two message queue types: standard queues and FIFO queues. Standard queues offer high throughput, but do not guarantee strict message ordering or exactly-once delivery. Conversely, FIFO queues make these guarantees, but have lower throughput than standard queues.

Amazon SQS has two types of queues available: standard queues and first-in-first-out (FIFO) queues. Amazon SQS standard queues and Pub/Sub both guarantee that each message will be delivered at least once. Similarly, the two services have comparable limitations: each may have occasional message duplication, and neither make guarantees about message delivery order.

Amazon SQS FIFO queues mitigate both problems by supporting exactly-once, ordered delivery of messages. The FIFO queues have a limit of 300 transactions per second.

Though Pub/Sub does not provide FIFO-style deduplication and message order guarantees, it's possible to achieve this functionality at the application level. For guidance, see Message Ordering (using ordering keys).

Maximum payload sizes

Google allows max 10MB payloads, which applies to the sum of the sizes of all outstanding messages, including message data and attributes.

For AWS SQS the limit is 256 KB, but using the extended client library this can be extended to 2GB.

Dead letter queues

Dead-letter queues, which other queues (source queues) can target for messages that can't be processed (consumed) successfully. Dead-letter queues are useful for debugging your application or messaging system because they let you isolate problematic messages to determine why their processing doesn't succeed.

Delay queues

Postpone the delivery of new messages to a queue for a number of seconds, for example, when your consumer application needs additional time to process messages. If you create a delay queue, any messages that you send to the queue remain invisible to consumers for the duration of the delay period.

Billing

On Google Cloud there is independent quota and billing for publishers and subscribers while on AWS the owner of the queue bears all costs based on the amount of data transfer out of the queue and the number of requests.

All Amazon SQS API calls count as requests. A single request can have from 1 to 10 messages, with a maximum total payload of 256 KB. Each 64 KB chunk of the payload is billed as a single request.

Pub/Sub is priced based on the amount of data volume used for message delivery. Volume is calculated based on the message and attribute data for publish, pull, and push operations.