Why not adopt a fully async stack? (asyncpg + async SQLAlchemy + async Alembic)

[MohamedMostafa259]

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 in the documentation/README.
• I already searched in Google "How to do X" and didn't find any information.
• I already read and followed all the tutorial in the docs/README and didn't find an answer.

Commit to Help

• I commit to help with one of those options 👆

Example Code

- `uv add asyncpg`
- `uv run alembic init -t async <directory_name>`
- `async def` instead of just `def` for method endpoints

Description

Current State

• HTTP Layer: FastAPI (async, non-blocking)
• Database Driver: psycopg (synchronous, blocking)
• CRUD/ORM: SQLModel with sync Session
• Migrations: Alembic with sync engine

Proposed Solution

Adopt a fully async stack:

FastAPI (async) → Async SQLAlchemy → AsyncPG (async) → Async Alembic

Related

• PR: #2270: Full async stack implementation (proof of concept)

Operating System

Windows

Operating System Details

Windows 11

Python Version

3.14

Additional Context

No response

[mabuya02]

I think a fully async stack is valid, but I can see why it may not be the default for a starter template. FastAPI being async at the HTTP layer does not necessarily mean every layer must be async. Moving the template to async would affect more than the driver:

• Session to AsyncSession
• CRUD helpers
• dependencies
• tests
• transactions
• Alembic env.py
• relationship/lazy-loading behavior

For high-concurrency apps, asyncpg + AsyncSession can make sense. But for a general template, the current sync SQLModel/SQLAlchemy setup is simpler, easier to debug, and easier for new users to understand.