SQLAlchemy setup with FastAPI - Performance & Optimization

Performance: SQLAlchemy setup with FastAPI

MEDIUM IMPACT

This affects the server response time and database query efficiency, impacting how fast the API can send data to the user.

Setting up database sessions in FastAPI to handle requests

FastAPI

from sqlalchemy.ext.asyncio import AsyncSession, create_async_engine
from sqlalchemy.orm import sessionmaker

engine = create_async_engine('sqlite+aiosqlite:///./test.db')
AsyncSessionLocal = sessionmaker(engine, class_=AsyncSession, expire_on_commit=False)

async def get_db():
    async with AsyncSessionLocal() as session:
        yield session

Uses async SQLAlchemy engine and session to avoid blocking FastAPI's async event loop.

📈 Performance GainNon-blocking DB calls improve throughput and reduce API response latency

Setting up database sessions in FastAPI to handle requests

FastAPI

from sqlalchemy.orm import sessionmaker
from sqlalchemy import create_engine

engine = create_engine('sqlite:///./test.db')
SessionLocal = sessionmaker(bind=engine)

def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

Using a synchronous SQLAlchemy session in an async FastAPI app blocks the event loop during database calls.

📉 Performance CostBlocks async event loop causing slower response times under load

Performance Comparison

Pattern	DB Connection Type	Event Loop Blocking	Response Latency	Verdict
Synchronous SQLAlchemy session	Sync	Blocks event loop	Higher latency under load	[X] Bad
Async SQLAlchemy session with async driver	Async	Non-blocking	Lower latency, better throughput	[OK] Good

Rendering Pipeline

In FastAPI, the SQLAlchemy setup affects how quickly the server can process and respond to requests by managing database connections efficiently.

→Request Handling

→Database Query Execution

→Response Sending

⚠️ BottleneckSynchronous DB sessions block async request handling, delaying responses.

Optimization Tips

1Avoid synchronous SQLAlchemy sessions in async FastAPI apps to prevent blocking.

2Use async SQLAlchemy engine and sessions with async drivers like aiosqlite or asyncpg.

3Create and close database sessions per request using FastAPI dependencies to manage resources efficiently.

Performance Quiz - 3 Questions

Why is using a synchronous SQLAlchemy session in FastAPI problematic for performance?

A It causes the browser to re-render unnecessarily.

B It increases the size of the database.

C It blocks the async event loop causing slower API responses.

D It reduces the number of database connections.

DevTools: Network and Performance panels

How to check: Use Network panel to measure API response times; use Performance panel to check if server responses are delayed due to blocking calls.

What to look for: Look for long server response times and blocked async tasks indicating synchronous DB calls.

Practice

1. What is the main purpose of SessionLocal in a FastAPI app using SQLAlchemy?

easy

A. To create a new database session for each request

B. To define the database schema

C. To connect directly to the database engine

D. To store user authentication data

Solution

1. Step 1: Understand the role of SessionLocal

   SessionLocal is a session factory that creates new database sessions for each request to ensure safe and isolated database operations.

2. Step 2: Differentiate from other components

   The database schema is defined by models, the engine connects to the database, and user data is unrelated to SessionLocal.

3. Final Answer:

   To create a new database session for each request -> Option A

4. Quick Check:

   SessionLocal creates new sessions per request [OK]

Hint: SessionLocal always means a new session per request [OK]

Common Mistakes:

• Confusing SessionLocal with engine
• Thinking SessionLocal defines schema
• Assuming SessionLocal stores user data

2. Which of the following is the correct way to create the SQLAlchemy engine in FastAPI?

easy

A. engine = create_engine('sqlite:///./test.db', connect_args={'check_same_thread': False})

B. engine = create_engine('sqlite:///:memory:')

C. engine = create_engine('postgresql://user:pass@localhost/db')

D. engine = create_engine('mysql://user@localhost/db')

Solution

1. Step 1: Identify the common FastAPI SQLite engine setup

   FastAPI tutorials often use SQLite with the URL 'sqlite:///./test.db' and the argument to allow multiple threads.

2. Step 2: Check options for correctness

   engine = create_engine('sqlite:///./test.db', connect_args={'check_same_thread': False}) matches the typical FastAPI SQLite setup with connect_args to avoid threading errors.

3. Final Answer:

   engine = create_engine('sqlite:///./test.db', connect_args={'check_same_thread': False}) -> Option A

4. Quick Check:

   SQLite engine with check_same_thread=False [OK]

Hint: SQLite needs check_same_thread=False in FastAPI [OK]

Common Mistakes:

• Omitting connect_args causing threading errors
• Using wrong database URL format
• Confusing in-memory with file-based SQLite

3. Given this FastAPI SQLAlchemy session usage, what will print(user.name) output?

from sqlalchemy.orm import Session

def get_user(db: Session, user_id: int):
    return db.query(User).filter(User.id == user_id).first()

user = get_user(db=session, user_id=1)
print(user.name)

medium

A. None

B. The name of the user with id 1

C. Raises AttributeError

D. Raises SQLAlchemyError

Solution

1. Step 1: Understand the query behavior

   The query filters User by id=1 and returns the first match or None if not found.

2. Step 2: Analyze the print statement

   If a user with id=1 exists, user.name prints the name; otherwise, user is None and accessing name would error.

3. Final Answer:

   The name of the user with id 1 -> Option B

4. Quick Check:

   Query returns user object [OK]

Hint: Query.first() returns object or None; here user exists [OK]

Common Mistakes:

• Assuming print outputs None without checking user
• Expecting an error without verifying user exists
• Confusing filter with filter_by syntax

4. Identify the error in this FastAPI SQLAlchemy session usage:

def create_user(db: Session, user: UserCreate):
    db_user = User(name=user.name, email=user.email)
    db.add(db_user)
    # Missing db.commit()
    return db_user

medium

A. User model is not imported

B. db.add() should be db.insert()

C. Missing call to db.commit() to save changes

D. Function should return None

Solution

1. Step 1: Check session usage for saving data

   Adding an object to the session requires calling db.commit() to persist changes to the database.

2. Step 2: Verify other parts of the code

   db.add() is correct, User model import is assumed, and returning the new user is expected.

3. Final Answer:

   Missing call to db.commit() to save changes -> Option C

4. Quick Check:

   db.commit() needed after db.add() [OK]

Hint: Always commit after adding to session [OK]

Common Mistakes:

• Forgetting db.commit() after db.add()
• Using db.insert() instead of db.add()
• Returning wrong type from function

5. You want to set up SQLAlchemy with FastAPI to support multiple database types (SQLite, PostgreSQL) using environment variables. Which approach correctly configures the engine and session?

hard

A. Use sessionmaker() without binding engine

B. Hardcode SQLite URL in create_engine and ignore env vars

C. Create engine without URL and pass URL to sessionmaker

D. Use DATABASE_URL env var, pass it to create_engine, then create SessionLocal with sessionmaker(bind=engine)

Solution

1. Step 1: Use environment variable for database URL

   Reading DATABASE_URL from environment allows flexible switching between databases.

2. Step 2: Create engine with the URL and bind sessionmaker

   Pass the URL to create_engine, then bind the engine to sessionmaker to create SessionLocal.

3. Final Answer:

   Use DATABASE_URL env var, pass it to create_engine, then create SessionLocal with sessionmaker(bind=engine) -> Option D

4. Quick Check:

   Env var URL + engine + sessionmaker(bind=engine) [OK]

Hint: Always bind engine to sessionmaker using env var URL [OK]

Common Mistakes:

• Hardcoding URLs reduces flexibility
• Not binding engine to sessionmaker causes errors
• Passing URL to sessionmaker instead of create_engine