FastAPI streaming responses: how long should a dependency hold a connection?

A streaming response should hold a database connection only while the stream actually needs it. Separate an initial access lookup from database work performed during streaming, and check the installed FastAPI version before choosing a dependency cleanup pattern. Yield-dependency lifetime has changed across releases; copying current scope syntax into an older pinned service is not a valid fix.

Draw resource lifetime alongside the response

List every resource acquired for authentication, permission checks, query iteration and output generation. For each, mark its last use. A connection used only to resolve an account can often be released before a long external-model stream. A connection backing a live database cursor must remain usable until cursor work finishes or is cancelled. Returning StreamingResponse does not make that distinction automatically.

FastAPI's dependency documentation records the relevant version changes: streaming cleanup moved back after response completion in 0.118.0, and scope='function' was added in 0.121.0. The inspected project requirements pin 0.115.0, so that newer scope option is an upgrade-path example, not an available feature to assume in the existing application.

FastAPI: yield cleanup, streaming and version-specific scopes

An access-only lookup can have a shorter life

In a synthetic chat flow, acquire a connection, verify the account and membership, build a small immutable access context and release the connection. The stream uses that context and an external dependency without a database cursor. If the stream later writes messages, give those writes their own short transaction boundary. Do not keep an unused connection alive just because it was convenient to inject it near the route.

# Illustrative resource shape; adapt to installed framework versions.
async def resolve_access(pool, credential):
    async with pool.acquire() as conn:
        access = await verify_access(conn, credential)
        return AccessContext(user_id=access.user_id)
# stream(access_context) must not use conn after this boundary.

The context must contain stable authorized identifiers, not a detached lazy object that tries to query after release. Also decide whether long-running actions must recheck membership before a later consequential write. Releasing a connection early solves occupancy; it does not define authorization freshness for a stream that remains open while permissions change.

Measure occupancy as well as latency

Use an isolated service and a small test pool. Start several slow synthetic streams, then issue an unrelated short read. Record acquired connections, queued acquisition time, stream lifetime and cancellation cleanup. A healthy average response time can hide a pool exhausted by idle streams. Conversely, a long stream may legitimately hold a cursor if that is its declared data-delivery design.

Compare two implementations under the same workload: one retaining a connection through response completion and one releasing an access-only lookup before streaming. Do not claim a performance improvement until that comparison runs. Pool size, worker count, client backpressure and framework version all affect the result. Increasing the pool can merely transfer pressure to the database if the resource boundary remains wrong.

Cancellation must close the real owner

Disconnect a synthetic client midway through the stream and verify generator cleanup, cursor closure and transaction rollback where relevant. The connection owner should release exactly once and leave the pool reusable. Do not rely on a happy-path finally block that is never reached because another layer owns the generator. Inspect behavior through the actual ASGI stack, including middleware that may buffer output.

No concurrent streaming fixture was executed for this article. The resource timeline and measurement worksheet are proposed tests, bounded to disposable data. Before applying a change, run them against the pinned FastAPI and Starlette versions, then repeat only when the implementation or framework behavior changes. Keep response replay and reconnect semantics separate: they require a durable event contract, while this guide concerns how long a dependency owns a scarce connection.

AI chat streaming that survives reconnects

Observability for small teams: start with the failed customer task

Bring one API or data workflow and a sanitized failure example for a bounded implementation assessment.

AptixLabs saas development