Both [Cloud Tasks](https://docs.cloud.google.com/tasks/docs/dual-overview) and
[Pub/Sub](https://docs.cloud.google.com/pubsub/docs/overview) can be used to
implement message passing and asynchronous integration. Although they
are conceptually similar, each is designed for a different set of use cases.
This page helps you choose the right product for your use case.

## Key Differences

The core difference between Pub/Sub and Cloud Tasks is
in the notion of implicit vs. explicit invocation.

Pub/Sub aims to decouple publishers of events and subscribers to those
events. Publishers do not need to know anything about their subscribers.
Therefore, Pub/Sub gives publishers no control over the delivery of the
messages save for the guarantee of delivery. In this way, Pub/Sub
supports **implicit** invocation: a publisher implicitly causes the subscribers
to execute by publishing an event.

By contrast, Cloud Tasks is aimed at **explicit** invocation where
the publisher retains full control of execution. In particular, a publisher
specifies an endpoint where each message is to be delivered.

Overall, Cloud Tasks is appropriate for use cases where
a task producer needs to defer or control the execution timing of a specific
webhook or remote procedure call. Pub/Sub is optimal for more general
event data ingestion and distribution patterns where some degree of
control over execution can be sacrificed.

## Detailed feature comparison

| Feature | Cloud Tasks | Pub/Sub |
|---|---|---|
| Push using webhooks | Yes | Yes |
| At-least-once delivery guarantee | Yes | Yes |
| Configurable retries | Yes | Yes |
| Task/message creation deduplication | Yes | No |
| Scheduled delivery | Yes | No |
| Ordered delivery | No, enqueued task order is preserved on a best‑effort basis | Yes, with ordering keys |
| Explicit rate controls | Yes | Pull subscriber clients can implement [flow control](https://docs.cloud.google.com/pubsub/docs/flow-control-messages) |
| Pull using API | No | Yes |
| Batch insert | Yes | Yes |
| Multiple handlers/subscribers per message | No | Yes |
| Task/message retention | 31 days | Up to 31 days |
| Maximum size of task/message | 1MB | 10MB |
| Maximum delivery rate | 500 QPS/queue | No upper limit, subject to regional throughput quotas |
| Geographic availability | Regional | Global |
| Maximum push handler/subscriber processing duration | 30 minutes (HTTP) 10 minutes (App Engine Standard automatic scaling) 24 hours (App Engine Standard manual or basic scaling) 60 minutes (App Engine Flexible) | 10 minutes for push operations |
| Number of queues/subscriptions | 1,000 per project per region, more available through quota increase request | 10,000 per project |