When should an EF Core query disable tracking?
Separate read models from updates, and say what tracking costs.
Points worth saying
- Tracking keeps a snapshot so SaveChanges can find updates.
- Read-only endpoints pay for snapshots they never use.
- AsNoTracking is the default choice for queries that only return data.
A full answer
A tracked entity is stored in the change tracker with an original snapshot. That is what lets SaveChanges produce an UPDATE for the columns you edited. It costs memory and identity-map lookups.
A GET endpoint that returns a DTO does not need that snapshot. AsNoTracking skips it. The query is cheaper and the context will not accidentally persist a mutation you made while shaping a response.
Keep tracking when you load an entity, change it, and save it in the same context. For a disconnected update from a client, prefer loading the current row, copying allowed fields, and saving. Attaching a client object and marking the whole graph modified will overwrite columns the client should not own.
Mention identity resolution if the interviewer pushes. No-tracking queries can still use identity resolution when you opt in, which matters for graphs that repeat the same related row.
Mark your progress
Create a practice profile to mark this question.