Session connections not properly released when using FastAPI Depends, causing connection pool exhaustion

[R-Hichem-ansys]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the SQLModel documentation, with the integrated search.
• I already searched in Google "How to X in SQLModel" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to SQLModel but to Pydantic.
• I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

• I commit to help with one of those options 👆

Example Code

from fastapi import FastAPI, Depends
from sqlmodel import SQLModel, Field, create_engine, Session, select
from typing import Optional, List


# Database model
class User(SQLModel, table=True):
    id: Optional[int] = Field(default=None, primary_key=True)
    name: str
    email: str
    age: int

# Database setup
DATABASE_URL = "sqlite:///./test.db"
engine = create_engine(
    DATABASE_URL,
    echo_pool="debug",
)

def create_db_and_tables():
    SQLModel.metadata.create_all(engine)

def get_session():
    with Session(engine) as session:
        yield session


# FastAPI app
app = FastAPI()

@app.get("/users", response_model=List[User])
async def get_users(session: Session = Depends(get_session)):
    users = session.exec(select(User)).all()
    return users

@app.get("/users-session-begin", response_model=List[User])
async def get_users(session: Session = Depends(get_session)):
    with session.begin():
        users = session.exec(select(User)).all()
    return users

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)


@app.on_event("startup")
def on_startup():
    create_db_and_tables()
    seed_database()

def seed_database():
    with Session(engine) as session:
        # Check if data already exists
        existing_users = session.exec(select(User)).first()
        if existing_users:
            return
        
        # Seed data
        users = [
            User(name="John Doe", email="[email protected]", age=30),
            User(name="Jane Smith", email="[email protected]", age=25),
            User(name="Bob Johnson", email="[email protected]", age=35),
            User(name="Alice Brown", email="[email protected]", age=28),
            User(name="Charlie Wilson", email="[email protected]", age=32),
            User(name="Diana Davis", email="[email protected]", age=27),
            User(name="Eve Miller", email="[email protected]", age=29),
            User(name="Frank Garcia", email="[email protected]", age=31),
            User(name="Grace Martinez", email="[email protected]", age=26),
            User(name="Henry Rodriguez", email="[email protected]", age=33),
        ]
        
        for user in users:
            session.add(user)
        session.commit()

Description

Bug Description

When using SQLModel Session with FastAPI's Depends() dependency injection, database connections are not properly released back to the connection pool after request completion. This leads to connection pool exhaustion and application blocking when the pool limit is reached.

Environment

SQLModel version: 0.0.24
FastAPI version: 0.115.14
Database: SQLite
Python version: 3.12.5

Expected Behavior

Database connections should be automatically released back to the connection pool after each request completes, allowing the application to handle concurrent requests without exhausting the pool.

Actual Behavior

Connections remain checked out from the pool and are not released, causing:

• Connection pool exhaustion after a few requests
• New requests block for the default timeout duration (30s)
• Application becomes unresponsive under load

Steps to Reproduce

• Run the above FastAPI application
• Make multiple requests to /users endpoint (via k6 for example)
• Observe that the request hangs for ~30 seconds before timing out

If you change the endpoint to hit the /user-session-begin, notice that this issue does not happen.

##Questions

• Is this expected behavior or a bug in SQLModel's integration with FastAPI?
• Should explicit transaction management (via session.begin()) be required for proper connection cleanup?
• Are there recommended patterns for using SQLModel sessions with FastAPI dependencies?

Operating System

Linux

Operating System Details

PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.2 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
UBUNTU_CODENAME=noble

SQLModel Version

0.024

Python Version

3.12.5

Additional Context

sample k6 script to load test

import http from 'k6/http';
import { check } from 'k6';
import { Rate } from 'k6/metrics';

// Custom metrics
export let errorRate = new Rate('errors');

export let options = {
  iterations: 5000,
  vus: 100, // 100 virtual users hitting as fast as possible
  thresholds: {
    http_req_duration: ['p(95)<10000'], // 95% of requests must complete within 10s
    http_req_failed: ['rate<0.8'],      // Allow higher error rate for stress test
  },
};

const BASE_URL = 'http://localhost:8000';

export default function () {
  let response = http.get(`${BASE_URL}/users`);
  
  let result = check(response, {
    'status is 200': (r) => r.status === 200,
    'response time < 10000ms': (r) => r.timings.duration < 10000,
    'response has content': (r) => r.body.length > 0,
  });
  
  errorRate.add(!result);
  
  // No sleep - hit as fast as possible
}

export function handleSummary(data) {
  return {
    'load-test-results.json': JSON.stringify(data, null, 2),
    stdout: `
=====================================
LOAD TEST SUMMARY
=====================================
Total Requests: ${data.metrics.http_reqs.count}
Failed Requests: ${data.metrics.http_req_failed.count}
Average Response Time: ${data.metrics.http_req_duration.avg.toFixed(2)}ms
95th Percentile: ${data.metrics.http_req_duration['p(95)'].toFixed(2)}ms
Max Response Time: ${data.metrics.http_req_duration.max.toFixed(2)}ms

Queue Exhaustion Indicators:
- High response times (>2000ms): ${data.metrics.http_req_duration['p(95)'] > 2000 ? 'YES' : 'NO'}
- Failed requests: ${data.metrics.http_req_failed.count > 0 ? 'YES' : 'NO'}
- Timeouts: Check for 5xx errors or timeouts above
=====================================
    `,
  };
}

[vishal-ramesh2]

I'm facing a similar issue, but when using SQLModel with Celery workers. When I process a lot of tasks really quickly, the connection pool gets exhausted

[YuriiMotov]

This issue comes from FastAPI, not SQLModel.
fastapi/fastapi#12066

If I'm right, it will only happen when you specified the response model. Try removing response model from your endpoint (or, return JSONResponse directly to bypass the response validation) and this should work without errors.

UPD: in the initial code example there is even more obvious problem - blocking database IO is used inside async ednpoint functions. So, it should be either refactored to using async DB interactions, or endpoint functions should be converted to sync (just def, not async def)

[vishal-ramesh2]

But my application does not use FastAPI. I'm using only celery to do some data processing tasks. It got resolved for me when I explicitly closed the session at the end of my task.

[YuriiMotov]

Could you provide an MRE?