MongoDB async ODM vs SQLAlchemy sessions

WHAT THIS TESTS Whether you grasp that MongoDB's access model is fundamentally different from a relational database. The interviewer wants to see that you do not blindly transplant SQLAlchemy's session and unit-of-work concepts onto a document store.

A GOOD ANSWER COVERS Motor is the official async MongoDB driver. You create one AsyncIOMotorClient for the whole application; it manages an internal connection pool, so there is no per-request session to open and close like SQLAlchemy's AsyncSession. There is also no identity map, no flush, and no implicit transaction boundary per request. Beanie is an async ODM built on Motor and Pydantic: you declare Document classes that map to collections, then call init_beanie once during the lifespan startup, passing the database handle and your document models. A find then looks like await User.find(User.age > 18).to_list() or await User.find_one(User.email == value). Because documents are schemaless and self-contained, you model embedded data rather than relying on joins.

COMMON WRONG ANSWERS Creating a new client on every request, which exhausts connections. Claiming you must scope a session per request as with SQLAlchemy. Assuming multi-document ACID transactions work the same as SQL without noting they require a replica set and explicit session objects.

LIKELY FOLLOW-UPS How do indexes and the aggregation pipeline differ from SQL queries? How would you do a multi-document transaction? How do you inject the Beanie models or client into endpoints?

ONE CONCRETE EXAMPLE In the lifespan handler you write client = AsyncIOMotorClient(uri) then await init_beanie(database=client.app_db, document_models=[User]). An endpoint becomes async def list_adults(): return await User.find(User.age >= 18).to_list(). No Depends-injected session is needed because Motor pools connections globally, and Beanie awaits the cursor directly.