Amazon Simple Queue Service (SQS) vs. Google Cloud Pub/Sub

While we use AmazonSimple Queue Service (SQS) in our serverless applications, it would be a great option to handle queue management for any internet-connect application. It provides the most benefit in situations where your application or service must maintain mission-critical queue of messages or jobs. If you're already using other AWS services you will find the greatest benefit.

Incentivized

Using Google Cloud Pub/Sub will mainly depend on the cloud platform used. Our client didn't choose GCP for Google Cloud Pub/Sub, if we went with AWS we would be using SNS/SQS (obviously). However, Google Cloud Pub/Sub is a better solution in the GCP services compared to self-managed solutions such as RabbitMQ for instance (it is managed by GCP and integrates with GCP solutions).

Incentivized

• SQS is reliable and fully managed. Our engineers do not have to worry about running RabbitMQ.
• SQS is very inexpensive.
• SQS allows data to be encrypted in transit, which may be required for compliance in some products.
• FIFO queues provide exactly-once processing.

Incentivized

• A hands-off approach to publishing messages and subscribing to topics.
• Easy to use APIs.
• Useful, simple UI on cloud console to send messages for debugging, etc.

Incentivized

• More frequest polling will be expensive
• No detailed monitoring of queues, just current data and regular monitoring is present
• No way to fetch messages back from the queue

• It is limited to work with the same platform but with different datasets at the same time, you must request a prior security authentication.
• It can sometimes lead to unexpected charges, as Pub/Sub will automatically keep on retrying messages continuously, even if failures are due to permanent code-level issues.
• Message re-deliveries don't apply for ingested services like with Python based client. Push messages tried to be delivered immediately and if your service is busy dealing with some other task, it won't be done OR goes into a queue

Incentivized

It serves all of our purposes in the most transparent way I can imagine, after seeing other message queueing providers, I can only attest to its quality.

It has many libraries in many languages, google provides either good guides or they're AI generated code libraries that are easy to understand. It has very good observability too.

I have never faced a single problem in 4 years.

It's very fast, can be even better if you use protobuf.

Online blogging and documentation for SQS is great. There are many examples of implementing it and if you look hard enough, more than likely there are examples that meet the exact case with which you are working

Incentivized

They have decent documentation, but you need to pay for support. We weren't able to answer all our questions with the documentation and didn't have time to setup support before we needed it so I can't give it a higher rating but I think it tends to be a bit slow unless you're a GCP enterprise support customer.

Incentivized

To be blunt: Amazon SQS was the simplest to implement given our requirements. Other services in this space work just as well, and SQS does not have any benefits outside of being the easiest to implement when using an otherwise fully AWS stack. AWS itself even has other solutions that would work just as well, however, SQS had the most reasonable pricing model for our given situation. That will certainly not always be the case, but in several of the instances where we are using it, it just made the most sense.

Incentivized

• Easy to setup Publisher, Subscribers and Message Queue service
• More Reliable and Easy Scalable with Google Managed services
• Easily integrated with most of the data sources we typically use for Data Storage and Analysis
• 10k Topics is a good enough number to build and deliver the business use cases
• Asynchronous and fallback mechanisms are great to ensure parallel delivery of the messages

Incentivized

You can just plug in consumers at will and it will respond, there's no need for further configuration or introducing new concepts. You have a queue, if it's slow, you plug in more consumers to process more messages: simple as that.

• Under the AWS Echo system, it provides great operating power to the application.
• The cost is much less for messages, and it also supports a multi-user option.
• Not for us, but for a larger organization, low throughput might become an issue for a standard queue type.

Incentivized

• Pub/Sub has helped avoid data loss improving our customer value prop.
• Pub/Sub has reduced development time that would otherwise be needed to build a highly scalable queue.

Incentivized