Connection pooling in FastAPI - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

How does connection pooling affect FastAPI app performance?

Consider a FastAPI app using a database connection pool. What is the main effect of using connection pooling on the app's performance under high load?

A It disables database access to improve API response speed.

B It increases latency because it opens a new connection for every request.

C It causes the app to crash when many requests come in simultaneously.

D It reduces latency by reusing existing database connections instead of opening new ones for each request.

💡 Hint

Think about how opening a new connection each time affects speed.

Connection pooling keeps a set of open connections ready to use. This avoids the overhead of opening and closing connections repeatedly, which reduces latency and improves performance under load.

📝 Syntax

intermediate

Identify correct connection pool setup in FastAPI with async SQLAlchemy

Which code snippet correctly creates an async connection pool for a PostgreSQL database using SQLAlchemy in FastAPI?

A engine = create_async_engine('postgresql+asyncpg://user:pass@localhost/db', pool_size=10, max_overflow=20)

B engine = create_async_engine('postgresql+asyncpg://user:pass@localhost/db', poolclass=QueuePool, pool_size=10)

C engine = create_async_engine('postgresql+asyncpg://user:pass@localhost/db', poolclass=NullPool)

D engine = create_async_engine('postgresql+asyncpg://user:pass@localhost/db', pool_size='ten')

💡 Hint

Check the parameter names and types for connection pool configuration.

Option A correctly uses pool_size and max_overflow to configure the connection pool size. Option A uses poolclass but QueuePool is default and requires import. Option A disables pooling. Option A uses a string instead of an integer for pool_size, causing an error.

🔧 Debug

advanced

Why does the FastAPI app exhaust connections despite using a pool?

Given this FastAPI code snippet, why might the app run out of database connections under heavy load?

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

engine = create_async_engine('postgresql+asyncpg://user:pass@localhost/db', pool_size=5)
async_session = sessionmaker(engine, class_=AsyncSession, expire_on_commit=False)

async def get_db():
    session = async_session()
    yield session

@app.get('/items')
async def read_items(db: AsyncSession = Depends(get_db)):
    result = await db.execute('SELECT * FROM items')
    return result.fetchall()

A The SQL query syntax is invalid, causing connection leaks.

B The sessions are not closed properly, causing connections to stay open and exhaust the pool.

C The pool size is too large, causing too many connections to open.

D The async_session is not awaited, so connections are never released.

💡 Hint

Look at how sessions are managed and closed.

The get_db() dependency creates sessions but does not close them properly (no async with or explicit await session.close() in a finally block). This causes connections to leak and exhaust the pool under heavy load.

❓ state_output

advanced

What is the maximum number of simultaneous DB connections with this pool config?

Given this connection pool configuration in FastAPI using SQLAlchemy, what is the maximum number of simultaneous database connections that can be open?

engine = create_async_engine(
    'postgresql+asyncpg://user:pass@localhost/db',
    pool_size=3,
    max_overflow=2
)

A 5 connections maximum

B 3 connections maximum

C 2 connections maximum

D Unlimited connections

💡 Hint

Remember that max_overflow adds extra connections beyond the pool size.

The pool_size sets the number of persistent connections (3). The max_overflow allows up to 2 additional temporary connections beyond the pool size. So total max connections = 3 + 2 = 5.

🧠 Conceptual

expert

Why prefer async connection pooling in FastAPI over sync pooling?

In a FastAPI app using async endpoints, why is it better to use an async connection pool rather than a synchronous one?

A Async pooling disables connection reuse, forcing new connections each time.

B Sync pooling is faster because it uses blocking calls, which are better for async apps.

C Async pooling allows non-blocking database calls, improving concurrency and throughput in async endpoints.

D Sync pooling automatically converts sync calls to async, so no difference exists.

💡 Hint

Think about how async code handles waiting for I/O.

Async connection pools use non-blocking calls, allowing the app to handle many requests concurrently without waiting for database responses. Sync pools block the event loop, reducing concurrency and performance in async apps.