Python Asyncio: When It Helps and When It Hurts

I see asyncio added to projects that do not need it. The mental model is often wrong: people treat async def as 'makes it fast.' It does not. Asyncio is an IO-concurrency tool. Use it where it fits, not as a default.

Where Asyncio Wins

Asyncio shines when you have many IO-bound operations: HTTP calls, database queries, file reads. The event loop juggles hundreds of in-flight operations while each one waits on the network. A synchronous version would wait on them one at a time.

import asyncio, httpx
 
async def fetch_all(urls):
    async with httpx.AsyncClient() as client:
        tasks = [client.get(u) for u in urls]
        return await asyncio.gather(*tasks)
 
# 20 URLs, 200ms each: 200ms total, not 4s
results = asyncio.run(fetch_all(urls))

That is a real 20x speedup on IO-bound work. Worth the async complexity.

Where Asyncio Hurts

CPU-bound work blocks the event loop. If you do a heavy computation inside an async function, every other coroutine stalls until it finishes. You get all the complexity of async with none of the concurrency benefit.

For CPU-bound work reach for multiprocessing or concurrent.futures.ProcessPoolExecutor, not asyncio. Different problem, different tool.

The Test I Use

Ask: is this function waiting on something external, or doing something itself? Waiting means async fits. Doing means it does not. That simple test has prevented more async-regret in my codebases than any style guide.

The Interoperability Tax

Async code and sync code do not mix easily. A sync function that needs to call async code has to wrap in asyncio.run. Async functions calling sync blocking code block the loop unless wrapped in run_in_executor. This tax is real. Plan the boundary once at the app edge, and keep the interior homogeneous.

See the Python asyncio docs for patterns. Asyncio is a scalpel. Powerful for IO, dangerous elsewhere.