What is change tracking in EF Core?
Quick Answer
Change tracking is how EF Core knows what to save. When you query with tracking (the default), the context keeps a snapshot of each entity and assigns it a state — Unchanged, Added, Modified, Deleted. On SaveChanges(), EF compares current values to the snapshot and generates only the necessary SQL. Read-only queries should use AsNoTracking() to skip this overhead.
Change tracking is how EF works out what SQL to run on SaveChanges. When I query normally, the context keeps a snapshot of every entity and a state — added, modified, deleted or unchanged. SaveChanges diffs the current values against the snapshot and only updates the columns that actually changed. The context is also an identity map, so loading the same row twice gives me the same object. The catch is that tracking costs memory and time, so for anything I'm only reading — a list for an API response, a report — I add AsNoTracking. And in a web API, entities from the request body aren't tracked, so I usually load the real entity and copy the changed values onto it rather than calling Update, which marks everything dirty.
Every tracked entity has an EntityState:
Added—INSERTon save.Modified—UPDATE(only changed columns by default).Deleted—DELETE.Unchanged— nothing.Detached— not tracked.
The context is also an identity map: query the same row twice in one context and you get the same object instance.
Performance: tracking builds snapshots and scans them on save. For queries you only read from (lists, reports, API GET), AsNoTracking() is faster and uses less memory. AsNoTrackingWithIdentityResolution() keeps de-duplication without full tracking.
Disconnected scenarios (web APIs): an entity coming from the client isn't tracked. You either Attach + set state, use Update() (marks everything modified), or load the existing entity and copy values onto it (safest — respects concurrency and avoids over-posting).