Editor’s note: This Google Pub/Sub review is based on my hands-on test of the Pub/Sub client workflow against Google’s official emulator (version 0.8.36, October 2026) with the Python client library, plus the hosted service’s documented behavior, published rates and quotas as of October 2026; billing, regional quotas and export paths were evaluated that way, not run. I weigh pricing transparency, real-world adoption signals, development momentum, openness and exit costs, practitioner sentiment and my own verdict.
Quick verdict: I recommend Google Pub/Sub for GCP-centered teams with spiky or unpredictable event volumes who want zero capacity planning, per-message acks and direct delivery into BigQuery without a Dataflow job. Go in knowing that it bills $40 per TiB in each direction, so every extra subscription re-bills the same bytes, and that Google’s own estimates put its Managed Service for Apache Kafka at roughly half the cost for steady 10 to 100 MiB/s loads.
Key Takeaways
- First 10 GiB a month free, then $40 per TiB on publish and again on every subscription’s delivery, with a 1 KB minimum per request.
- No partitions, shards or brokers: in my test one script created 12 topics and 15 subscriptions and moved 5,000 messages in under a second.
- Ordering is opt-in at 1 MBps per key; exactly-once is pull-only, regional and capped at 180,000 messages a minute in most regions.
- Pub/Sub Lite, the reserved-capacity tier at $169 a month where Pub/Sub costs $2,000, was scheduled for turndown on March 18, 2026.
- JavaScript transforms ($40 per TiB) went GA in June 2025; 2026 added AI inference transforms ($60 per TiB), Bigtable subscriptions and an MCP server.
Among the streaming platforms in the Panoply directory it is the only one with no cluster to run at all; Apache Kafka, Confluent and Redpanda all ask you to think in partitions.
In this review, I’ll take a closer look at Google Pub/Sub’s pricing, what it was like to set up and break, its delivery guarantees, the BigQuery and Cloud Storage subscriptions, the 2026 transforms, and how it stacks up against Managed Kafka, Confluent, Redpanda and Kinesis, so you can see whether it belongs under your pipelines.

Google Pub/Sub Pros and Cons
Pros
- No partitions, shards or brokers to size; publisher quota is 4 GB/s per large region.
- First 10 GiB a month free, then $40 per TiB, and the emulator runs locally with no account.
- BigQuery, Cloud Storage and Bigtable subscriptions land data with no Dataflow job ($50 per TiB).
- Per-message acks, dead-letter topics (5 to 100 attempts), filters, snapshots and 31-day topic retention.
- Inline transforms: JavaScript UDFs at $40 per TiB, AI inference (2026) at $60 per TiB, plus a GA MCP server.
Cons
- Every subscription re-bills the same bytes: 10 MiB/s with 2 subscriptions is $3,000 a month, not $2,000.
- Google’s own table prices Managed Kafka at about $1.1K where Pub/Sub costs $2,000 at 10 MiB/s.
- Exactly-once is pull-only, regional, slower, and does not cover publisher retries.
- Ordering keys cap at 1 MBps each and one redelivery re-sends every later message on that key.
How Much Does Google Pub/Sub Cost?

Google Pub/Sub has no plans: it bills $40 per TiB of throughput in every region after the first 10 GiB a month, and it bills that rate twice, once when you publish and again for every subscription that delivers the bytes.
- Basic delivery ($40 per TiB): for publish and for pull or push delivery; the first 10 GiB a month is free.
- Export subscriptions ($50 per TiB): for BigQuery, Cloud Storage and Bigtable writes, with no free tier and no separate BigQuery ingestion charge.
- Import topics ($50 or $80 per TiB): for Kinesis Data Streams at $50 and Cloud Storage, Azure Event Hubs, AWS MSK or Confluent Cloud at $80, plus the source cloud’s egress.
- Message storage ($0.27 per GiB-month): for topic retention, retained acked messages, snapshots and any unacked backlog older than 24 hours.
- Single message transforms ($40 or $60 per TiB): for JavaScript UDFs at $40 and AI inference at $60, with model charges extra.
| Component | Rate | Free allowance | What triggers it |
|---|---|---|---|
| Basic delivery | $40 per TiB | 10 GiB a month | Publishing, plus pull or push delivery on each subscription |
| Export subscriptions | $50 per TiB | None | BigQuery, Cloud Storage or Bigtable subscription writes |
| Import topics | $50 or $80 per TiB | None | Kinesis at $50; Cloud Storage, Event Hubs, MSK or Confluent Cloud at $80 |
| Message storage | $0.27 per GiB-month | First 24 hours of unacked backlog | Topic retention, retained acked messages, snapshots, older backlog |
| Single message transforms | $40 or $60 per TiB | None | JavaScript UDF at $40, AI inference at $60 on the larger of input and output |
| Data transfer | VPC network rates | No zone fees, inbound free | Cross-region delivery and internet egress |
What a Real Workload Costs
My arithmetic for 5,000 messages a second at 2 KB with 3 subscriptions: about 23.6 TiB published and 70.7 TiB delivered a month, roughly $3,770 before storage. Google’s own worked example prices 10 MiB/s with 1 subscription at $2,000 a month and 2 subscriptions at $3,000, then 100 MiB/s at $19,760 and $29,640.
The same example priced Pub/Sub Lite at $169 (zonal) to $608 (regional) for 10 MiB/s, the step-up every former Lite user faces.
The 1 KB minimum is per request, not per message: a 300-byte message published alone bills as 1,000 bytes, so leave client batching on (the default).
Since June 30, 2024, unacked messages older than 24 hours bill at $0.27 per GiB-month, which RevenueCat’s team warned hits idle subscriptions and endpoints that return non-200 to keep messages as a backup; the cheapest fix is topic retention, shared by every subscription.
Google’s own estimate for its Managed Service for Apache Kafka is about $1.1K a month at 10 MiB/s and $11K at 100 MiB/s, against $2,000 and $19,760 here.
Is Google Pub/Sub Good Value for Money?
- Good fit: under a few TiB a month, spiky traffic, 1 or 2 subscriptions and a team with nobody to run brokers; xMatters kept a job queue of 578-byte JSON messages inside the free tier.
- Less convincing fit: steady 10 MiB/s and up with several subscriptions, where Managed Kafka runs at about half the price and keeps retention limited by disk rather than 31 days.
- Budget priority: count subscriptions, not topics, and check average message size against the 1 KB minimum before you estimate.
Reviewer’s Notes: I recommend starting on the free tier with topic retention set to 1 day and one BigQuery subscription per topic. When more consumers arrive, put the ones that need only a slice of the stream behind one filtered subscription instead of a full copy each; a third full subscription at 10 MiB/s adds $1,000 a month.
My Experience With Google Pub/Sub

I tested the client workflow against Google’s official emulator (0.8.36) with google-cloud-pubsub 2.38.0 on my laptop, so every timing below is a loopback emulator number, not cloud latency.
Setting Up a Topic and Pulling Messages
Setup was one pip install google-cloud-pubsub, one environment variable (PUBSUB_EMULATOR_HOST=localhost:8085) and no account, project or credentials. The emulator is a single 53 MB Java jar that needs a modern JRE: the Mac’s stock Java 8 would not run it, and the Cloud SDK refused the Mac’s Python 3.9 outright, so I ran the jar directly.
create_subscription with only a name and a topic returned a 10 s ack deadline and 7-day retention.
5,000 publishes of 200-byte messages with default client batching took 0.22 s, and a synchronous pull with max_messages=1000 drained and acked all 5,000 in 0.23 s. Streaming pull with a callback ran at a p50 of 154 ms publish-to-callback on loopback.
Ordering, Deadlines and Replay
Publishing with an ordering key on a client created without enable_message_ordering fails with a ValueError before any bytes leave the machine. 200 messages on one key arrived in order on the ordered subscription; an unordered subscription on the same topic promises nothing.
A pulled message I never acked came back at exactly 10.0 s, and modify_ack_deadline set to 0 acted as a nack with immediate redelivery. The API refused an ack deadline of 601 s as out of bounds, max_delivery_attempts of 200 (the cap is 100), and topic retention of 32 days (31 was accepted).
Bodies of 10,485,761 and 10,484,736 bytes were both refused client-side: the publish request cap is 10,000,000 bytes, so “10 MB” is decimal. An Avro schema attached to a topic rejected a record with amount “nine” at publish with “Could not parse message”.
A subscription filtered on attributes.type = “refund” delivered exactly the 3 refunds out of 5 publishes, and the filter is immutable afterwards; you recreate the subscription. Snapshot then seek re-delivered 5 events I had already acked.
Push to a local HTTP endpoint arrived as JSON with base64 data, messageId and publishTime; two 500s from my endpoint produced retries at +1.2 s and +2.3 s, then a 204 acked it.
What the Emulator Will Not Show You
The emulator accepted the exactly-once flag and a BigQuery and a Cloud Storage subscription but delivers nothing for them, and it never forwarded my nacked poison message to the dead-letter topic in 40 s. Dead-letter forwarding, dedupe under load, OIDC push auth, export delivery, transforms and the console are therefore documented behavior here, not something I ran.
Reviewer’s Notes: The API refusing bad settings before anything is stored impressed me most: ack deadline, attempt cap, retention cap and schema all failed fast with a readable error. Budget for the consumer side: redelivery at the ack deadline and nack-on-error both re-send, so idempotent consumers are not optional.
Delivery Guarantees: Ordering, Exactly-Once and Dead Letters

A plain Pub/Sub subscription is at-least-once and unordered, and each stronger guarantee is a subscription setting with its own ceiling.
Ordering Keys
Ordering is opt-in per key with a 1 MBps publish limit, and keys are not partitions: Google says they scale to billions. If one message on a key is redelivered, every later message on that key is re-sent, acked ones included.
A practitioner on Google’s developer forum had a single user_id key stall for days until the subscriber restarted. An engineering team’s write-up blamed multi-threaded consumers, autoscaled workers and redelivery after timeouts for non-deterministic order even with keys, and settled on subscriber-side sorting.
Keep ordered and unordered traffic on separate topics, publish a key’s messages from one region, and leave ordering off on any subscription that feeds Dataflow.
Exactly-Once Delivery
Exactly-once works only on pull and StreamingPull subscriptions inside one region, with quotas of 1,000,000 messages a minute in us-central1 but 180,000 a minute (roughly 3,000 a second) in most regions. Acking an expired ID returns INVALID_ARGUMENT instead of OK, so you need ack-with-response, which arrived in Python 2.13.6, Java 1.139.0, Go 1.25.1 and Node 3.2.0.
It does not dedupe publishes, because a publisher retry creates a new message ID, and combined with ordering it drops to thousands of messages a second. A practitioner on Google’s developer forum still saw expiries and duplicates with a 600 s deadline, because the client library’s lease management (up to an hour by default) governs the real deadline.
Dead Letters, Retries and Push Backoff
A dead-letter topic forwards after 5 to 100 attempts (default 5), forwarding is best-effort, and the attempt counter can reset when a pull subscription’s subscribers go idle. Retry is immediate by default or exponential backoff between 0 and 600 s (defaults 10 s and 600 s), and nacking a large batch can slow delivery of every message on the subscription.
Push adds its own subscription-wide backoff of 100 ms to 60 s that cannot be tuned or turned off. One Hacker News commenter summed up production as “duplicated messages, shitty DLQ implementation” and “infinite resends” from consumers that nacked on every error, and still called the scaling and low cost worth it.
xMatters saw several instances pick up the same unacked job and added their own ownership check; a message published before a subscription exists is usually not delivered. Kafka gives you transactions and consumer-group offsets; Pub/Sub has no transactions and Google points to Dataflow for dedupe.
Build idempotent consumers on day one, whichever flags you turn on.
Getting Data Out: BigQuery, Cloud Storage and Bigtable Subscriptions

A BigQuery subscription writes every message into a table through the Storage Write API for $50 per TiB, with no Dataflow job and no separate BigQuery ingestion charge (table storage still applies).
- BigQuery: use_topic_schema maps Avro or Protobuf fields to columns and write_metadata adds message_id, publish_time and attributes; a badly formatted field means the message is not written; CDC mode with a _CHANGE_TYPE field needs a primary-key table; delivery is at-least-once.
- Cloud Storage: batches messages by size and time into objects that become visible only when the object is finalized; failures back off like push and can dead-letter.
- Bigtable: in Preview since April 16, 2026, writes through an app profile with single-cluster routing, at-least-once, and a failed write nacks with an error attribute for dead-lettering.
When You Still Need Dataflow
Dataflow stays in the picture for windowing, aggregation, joins and exactly-once landing: the Pub/Sub-to-BigQuery Dataflow template is exactly-once by default, while the subscription is at-least-once. For “events into BigQuery, nothing else” the $50 per TiB subscription is the cheapest path on GCP; the moment you need a window, you are paying for Dataflow workers on top.
Import topics run the other way at $50 per TiB from Kinesis and $80 from Cloud Storage, Event Hubs, MSK or Confluent Cloud, plus the source cloud’s egress; MSK import works only from public provisioned clusters and always reads from the earliest offset.
On AWS, Kinesis plays the same landing role; on GCP the Pub/Sub subscription bills per TiB and ends in BigQuery with no consumer code.
Transforms, Schemas and the 2026 Additions

A topic or subscription can run a JavaScript function on every message for $40 per TiB (GA since June 2, 2025), and on a topic it runs before the message is stored.
- JavaScript UDF transforms: 20 KB of code, 500 ms per message, ECMAScript built-ins only, no network calls or imports, and return null to drop a message; Google’s redactSSN example deletes a field at publish so no subscriber ever sees it. Since October 1, 2026, Gemini Enterprise writes the UDF from a plain-English prompt in the console.
- AI Inference transform: GA since April 6, 2026 at $60 per TiB on the enriched size plus model charges; it calls Vertex AI endpoints or Gemini and Claude models and wraps output as {original_message, model_output}; not supported with unary pull.
- Schemas: Avro 1.11 and Protocol Buffers, 300 KB definitions, 20 revisions and one top-level type per schema; in my test an invalid record was refused at publish.
- Filters: 256 bytes, attribute-only, hasPrefix is the only function, immutable; anything bigger belongs in a UDF.
- MCP server: GA since April 17, 2026 on global and locational endpoints; an agent can create and delete topics, subscriptions and snapshots and publish messages, with Gemini CLI and Claude Code named as clients.
- Client libraries: C#, Go, Java, Node.js, PHP, Python and Ruby; the v1 Go library and the v2 Ruby library stop receiving fixes on July 31, 2026.
Admin operations are capped at 100 a second per project and Google says increases are rarely granted, so an agent creating resources or a topic-per-tenant design hits it fast, on top of the 10,000-topic ceiling that made xMatters abandon topic-per-customer. Flink on Confluent and Kafka Streams do stateful processing across messages; a transform here is stateless and sees one message at a time.
How Does Google Pub/Sub Compare to Competitors?

Pub/Sub stays my pick for spiky GCP workloads with 1 or 2 subscriptions; each rival below wins a niche it does not.
| Platform | Model | Price anchor | Wins when |
|---|---|---|---|
| Google Pub/Sub | Serverless, per byte | $40 per TiB per direction, 10 GiB free | Spiky volume, 1 or 2 consumers, BigQuery landing |
| Google Cloud Managed Service for Apache Kafka | Provisioned Kafka on GCP | $0.09 per DCU-hour, about $1.1K a month at 10 MiB/s | Steady throughput, Kafka API, transactions |
| Confluent Cloud | Managed Kafka, multi-cloud | Basic $0.14 per eCKU-hour plus $0.05 per GB in and out | Multi-cloud, Flink, connector catalog |
| Redpanda Cloud | Kafka API without the JVM | Serverless base compute from $0.10 per hour | Kafka clients with no JVM tuning |
| Amazon Kinesis Data Streams | AWS shards or on-demand | $0.08 per GB written, $0.04 per GB read, $0.04 per stream-hour | AWS-centered stacks |
| Azure Event Hubs | Azure throughput units | $0.015 (Basic) or $0.03 (Standard) per TU-hour plus $0.028 per million events | Azure-centered stacks |
| Apache Kafka, self-managed | Open source on your VMs | About $0.9K a month at 10 MiB/s on Compute Engine | Unlimited retention, full ecosystem, no vendor |
- Google Cloud Managed Service for Apache Kafka: Google’s own alternative at about $1.1K a month at 10 MiB/s against $2,000 for Pub/Sub, keeping the Kafka API, transactions and disk-limited retention; in return you size vCPUs and partitions and pay $0.01 per GiB of inter-zone replication.
- Confluent Cloud: Basic at $0.14 per eCKU-hour plus $0.05 per GB each way and $0.08 per GB-month storage, with Flink and the connector catalog on top; Pub/Sub imports from it at $80 per TiB.
- Redpanda Cloud: the Kafka API without the JVM, with Serverless capped at 100 MB/s write under a 99.9% SLA; its list rates differ across its own pages, so price it in the estimator.
- Amazon Kinesis Data Streams: the pick on AWS at $0.08 per GB written, $0.04 per GB read and $0.04 per stream-hour on-demand; Pub/Sub imports from it at $50 per TiB plus AWS egress.
- Azure Event Hubs: $0.015 (Basic) or $0.03 (Standard) per throughput-unit hour plus $0.028 per million events, 1 MB/s in per unit and a Kafka endpoint on Standard; the pick on Azure.
- Apache Kafka, self-managed: Google’s own estimate is about $0.9K a month at 10 MiB/s on Compute Engine, with unlimited retention and the full ecosystem; in return you run brokers, rebalancing and upgrades, the chore that sent xMatters to Pub/Sub.
Debezium feeds change events into either side, so a CDC source does not settle this choice; your throughput curve and your subscription count do.
How I Reviewed Google Pub/Sub
I ran the Python client against Google’s official emulator on my laptop: one script created 12 topics and 15 subscriptions and exercised publish batching, pull and streaming pull, ordering keys, ack deadlines and nacks, dead-letter and retry settings, filters, Avro schemas, snapshots and seek, size and retention caps, and a push endpoint that failed twice before acking.
I evaluated the hosted service from its published rates, quotas and stated behavior: the 99.95% SLA, exactly-once and ordering, export and import paths, the 2026 transforms and the MCP server.
I weighed pricing transparency, real-world adoption signals, development momentum, openness and exit costs, practitioner sentiment from Google’s developer forum, Hacker News and engineering blogs, and my own verdict. Rivals are compared on list prices. Prices current as of October 2026.
Should You Build on Google Pub/Sub?
I recommend Google Pub/Sub for teams already on GCP whose event volume is spiky and whose consumers number 1 or 2, especially when the destination is BigQuery, where the $50 per TiB subscription removes the Dataflow job. There are no partitions to size, the first 10 GiB a month is free, the API refuses bad settings before anything is stored, and 31-day topic retention gives you replay without a second system.
Skip it at a steady 10 MiB/s and up with 3 or more subscriptions, where Managed Service for Apache Kafka runs at roughly half the cost on Google’s own numbers. Skip it too if you need transactions or Kafka API portability, or if any ordered stream will exceed 1 MBps per key. The 99.95% SLA counts only publish failures lasting 60 seconds or more, so a subscribe-side incident earns no credit.
Run the emulator locally for an afternoon, then put one topic with a BigQuery subscription on the free tier at cloud.google.com/pubsub and watch the first month’s bill before you add consumers.
FAQ
Is Google Pub/Sub free?
Partly. The first 10 GiB a month of basic throughput is free; after that Pub/Sub bills $40 per TiB on publish and on each subscription’s delivery. BigQuery, Cloud Storage and Bigtable subscriptions have no free tier at $50 per TiB, and a new Google Cloud account adds $300 in credits.
Is Pub/Sub Lite still available?
Not anymore: Lite closed to new customers on September 24, 2024 and its turndown was scheduled for March 18, 2026, with Google pointing users to Pub/Sub or Managed Service for Apache Kafka. The cheapest Lite configuration ran $169 a month where Pub/Sub costs $2,000 at 10 MiB/s, so I would price Managed Kafka before moving a steady Lite workload to standard Pub/Sub.
How long does Pub/Sub keep messages?
Topic retention goes up to 31 days, a subscription keeps unacked messages for 7 days, and a snapshot lives at most 7 days. Storage beyond the first 24 hours of unacked backlog, plus any topic retention, retained acked messages and snapshots, bills at $0.27 per GiB-month, so set retention on the topic, which all subscriptions share.
Does Pub/Sub guarantee exactly-once delivery?
Only on pull subscriptions inside one region, with a ceiling of 180,000 messages a minute in most regions and no coverage for publisher retries, which create new message IDs; push and export subscriptions stay at-least-once. See Delivery Guarantees above for the ceilings, and build idempotent consumers either way.
Is Pub/Sub better than Kafka?
Different. I pick Pub/Sub for serverless, spiky workloads with per-message tracking and a BigQuery destination, and Kafka for portability, transactions, steady high throughput and retention measured in disk. Google’s own numbers put Managed Service for Apache Kafka at about $1.1K a month against $2,000 for Pub/Sub at 10 MiB/s with one subscription.






