A SaaS handling AI-powered email processing discovered that serverless workloads demand different job queue thinking. Here's what broke, and why Google Cloud Tasks won.
Twio processes emails for loan brokers using AI. The flow is straightforward: download, parse body and attachments, OCR, classify with an LLM, write structured data, and index for RAG. One email with five attachments easily becomes 30+ background jobs. Batch uploads become hundreds.
That multiplication matters. It's not about single-job throughput; it's about the cascading demand a serverless architecture creates when one triggering event spawns dozens of child tasks.
pg-boss is a solid job queue for applications running on stable, always-on infrastructure. It's open source, runs inside PostgreSQL (no new infrastructure to manage), and handles retries and scheduling without extra dependencies.
For Twio's initial workload on traditional servers, pg-boss worked fine. The problem wasn't the queue itself; it was the mismatch between pg-boss's design assumptions and serverless reality.
Serverless scales by spinning up new function instances. Each instance needs a database connection to check for jobs. When Twio hit burst workloads (batch uploads), the function count scaled faster than PostgreSQL could provision connections. pg-boss and the application fought for the same finite pool.
Twio explored Google Cloud's Pub/Sub and Cloud Tasks as alternatives. Both separate queue management from your database, letting serverless functions scale without connection pool contention. Cloud Tasks won the evaluation.
The decision came down to fit with Twio's workload: cascading job chains (one email spawning parsing, OCR, LLM, and indexing jobs) aligned better with Cloud Tasks' task scheduling model than pure pub/sub messaging.
Test your actual workload. Single-email processing. Batch uploads. Count the job multiplication. If you hit database connection failures or queue backlogs during volume spikes, a managed queue service built for serverless is your answer.
If your load stays steady and your infrastructure is always-on, pg-boss remains a pragmatic choice. Serverless with burst behavior demands isolation between your app and your queue.
Source: DEV Architecture, 'From pg-boss to Cloud Tasks: Fixing Queue Bursts and DB Connection Failures on Serverless' (2026).
How WebKing runs this
We help SaaS and commercial operations diagnose why their background job systems fail under scale, then architect around the actual bottleneck (database pools, job multiplication, or both). Twio's choice between pg-boss, Pub/Sub, and Cloud Tasks mirrors decisions most businesses face when email, document, or AI processing pipelines hit production.
Sources
The Lab is original analysis by WebKing. We summarize and interpret developments from the sources above for industrial, commercial, and small business owners. Figures are reported as published by their sources.
More from the desk
A game studio's near-fatal mistake: building infrastructure before understanding the actual problem. Here's what went wrong and how to avoid it in your own systems.
Independent deployment, not code splitting, is what actually lets teams move fast. How to structure frontend work so your checkout team doesn't wait on search.
Build-time composition keeps teams coupled. Here's what actually separates your frontend teams.
