When You Should Not Use Cloudflare Workers (And What to Use Instead)

Quick answer: Cloudflare Workers is not the right fit for jobs that need more than 128 MB of memory, jobs that read or write files on disk, code bundles larger than 10 MB, processing that burns more than 5 minutes of CPU, and databases larger than 10 GB on D1. In every one of those cases Cloudflare already has another service that fits: Containers, Workflows, Queues and Hyperdrive.

Most articles about Cloudflare Workers only tell you what it does well. That is not wrong, because Workers is genuinely excellent at the jobs it was designed for. But as a team that implements these systems for a living, we have learned that the most expensive mistakes do not happen while writing code. They happen when a team picks the wrong tool at the start and only finds out days before going to production.

So this article does the opposite. It tells you plainly which workloads you should not put on Workers, and what to use instead, based on the limits Cloudflare publishes officially as of July 2026.

The real limits of Cloudflare Workers

Before talking about scenarios, you need the actual numbers. These are the limits that matter most when making an architecture decision.

The two numbers to underline are 128 MB and 6 simultaneous connections, because they are identical on the free and paid plans. You cannot buy your way out of them. AWS Lambda, by contrast, lets you configure memory anywhere from 128 MB to 10,240 MB.

Seven situations where you should not use Cloudflare Workers

1. Jobs that load large amounts of data into memory

The 128 MB ceiling covers the JavaScript heap and any WebAssembly allocations together. If your job reads a 300 MB CSV into memory to process it, transcodes video, or loads a large machine learning model into memory, the Worker will die partway through and there is no paid tier that fixes it.

The correct answer is to redesign the job to stream data in chunks, or move that workload to Cloudflare Containers, where you can allocate far more memory.

2. Jobs that need to read or write files on disk

Workers has no filesystem access at all. There is no /tmp to write to. This single constraint rules out a surprising number of popular libraries, particularly image and document processing tools that write a temporary file and read it back.

Many teams discover this halfway through the build, which is the most expensive moment to change architecture. If your system depends on a library that touches the filesystem, check it on day one.

3. Code bundles over the size limit, or native Node modules

The paid plan caps compressed bundle size at 10 MB, which is plenty for most applications, but not if you are bundling an ML model or a heavy dependency tree.

More importantly, Workers does not run full Node.js. The nodejs_compat mode covers a lot of ground, but native modules compiled to binaries still will not run. If your existing system leans on several native modules, migrating to Workers is not a copy-paste exercise.

4. CPU-heavy processing that runs longer than 5 minutes

It is important to distinguish CPU time from waiting time. Cloudflare only counts the time your code is actually executing, not the time spent waiting on a database or an external API. This is one of the biggest advantages of Workers and a meaningful cost saving over Lambda.

But if your job genuinely uses CPU for more than 5 minutes at a stretch, such as video encoding, bulk image processing in a single pass, or a compute-heavy ETL run, Workers will terminate it.

Work like this should be broken into steps and handed to Workflows, or pushed onto Queues to be processed incrementally, rather than crammed into one request.

5. Systems that need many simultaneous outgoing connections

Workers allows only 6 simultaneous outgoing connections per invocation, and that ceiling is the same on both free and paid plans. If your code fans out 20 parallel requests to keep latency down, you will have to redesign it.

Traditional serverless also suffers from database connection pool exhaustion, because every invocation opens a fresh connection. Cloudflare solves this with Hyperdrive, which handles connection pooling and caching for you, letting you keep your existing PostgreSQL database instead of migrating it.

6. Databases larger than 10 GB on D1

D1 is SQLite running on Cloudflare network, and it has a hard ceiling of 10 GB per database, which cannot be raised.

This is a design decision, not a flaw. Cloudflare intends D1 to be scaled out across many small databases, for example one database per tenant or per user, which suits multi-tenant SaaS very well.

But if your system needs one large central database with heavy cross-table joins, D1 is the wrong answer. Keep your PostgreSQL and connect through Hyperdrive instead.

7. Batch or cron jobs that run longer than 15 minutes

Cron Triggers, Queue Consumers and Durable Object Alarms all cap out at 15 minutes of execution. A long overnight batch that must complete in a single run does not fit.

The right approach is to split the work into small units and let Queues process them steadily, or use Workflows, which is purpose-built for long-running multi-step jobs.

What to use instead

The good news is that Cloudflare already has a service for almost every limitation above, inside the same platform. You do not need to abandon Cloudflare.

Most architectures that actually work in production are therefore hybrid: Workers sits at the front handling routing and fast logic, then hands heavy work to Containers, Workflows or Queues.

When Workers is the right answer

To be fair, Workers is an excellent fit for the following, and usually clearly better than the alternatives.

APIs that must respond fast globally, because your code runs close to the user instead of travelling back to a single region, and there is no cold start of the kind Lambda has.

Workloads dominated by I/O waiting, such as APIs that call other services, or a backend-for-frontend aggregating several sources. Cloudflare bills on CPU time, not wall-clock time. A request that waits 200 ms on a database but only uses 5 ms of CPU is billed for 5 ms, whereas Lambda bills for the full 205 ms. At high traffic that difference compounds into a meaningful number.

Logic that sits between the user and an existing system, such as A/B testing, an authentication gateway, image resizing, header rewriting, or edge caching more sophisticated than a normal CDN can do.

Multi-tenant SaaS that can shard a database per customer, which maps neatly onto the D1 model.

Conclusion

Cloudflare Workers is not a cheaper Lambda. It is a different platform with a different set of trade-offs. Its strengths are speed, global distribution, and CPU-time billing, which is dramatically cheaper for I/O-bound work. Its weaknesses are the 128 MB memory ceiling, the absence of a filesystem, and the 6-connection limit, none of which you can pay to remove.

So the right question is not whether Workers beats Lambda. The right question is: which Workers limits does this specific workload run into, and does Cloudflare have another service that covers it? Most of the time, the answer is yes.

At Cipher we design and implement systems on the Cloudflare Developer Platform for businesses in Thailand, including the assessment of which workloads belong on Workers and which should move to Containers or Workflows. If you are considering a migration to Cloudflare and want to know which limits you will hit before you commit, we can assess it for you.

Frequently Asked Questions

How much memory does Cloudflare Workers have?

128 MB per isolate, on both the Free and Paid plans. This cannot be increased by paying more, unlike AWS Lambda which can be configured up to 10,240 MB. If your workload needs to load a large amount of data into memory, Workers may not be the right choice.

How long can a Cloudflare Worker run?

The Paid plan allows up to 5 minutes of CPU time per request, with a default of 30 seconds. The Free plan allows only 10 milliseconds. Note that this measures CPU time, not waiting time, so code that waits on a slow API is not billed or timed while it waits.

Can Cloudflare Workers write files to disk?

No. Workers has no filesystem access at all. Libraries that need to write temporary files, such as some image and video processing tools, will not run on Workers. Those workloads need to move to Cloudflare Containers.

What is the maximum size of a D1 database?

A single D1 database can hold up to 10 GB and this limit cannot be increased. D1 is designed to be scaled out across many smaller databases, for example one per user or per tenant. If your system needs a single database larger than that, use PostgreSQL with Hyperdrive.

If Workers is not suitable, which Cloudflare service should I use instead?

It depends on the constraint. For memory or filesystem limits, use Cloudflare Containers. For long multi-step jobs, use Workflows. For batch processing, use Queues. And if the issue is connecting to an existing database, use Hyperdrive.