You update an order status from Pending to Confirmed, call SaveChangesAsync, and get a clean 200 response. The next GET request on that order comes back Pending. You check the database directly — the row shows Confirmed. No Redis, no output caching, no CDN in the picture. Where is the stale data coming from?
The production-ready patterns covered here — including read/write separation at the repository layer and scope-safe DbContext usage — are available with full source code on Patreon, where the complete implementations are wired together as a running API, ready to adapt.
If you want to see how AsNoTracking, identity map behaviour, and read/write scope boundaries fit together inside a real production API, Chapter 3 of the ASP.NET Core Web API: Zero to Production course covers exactly this — with a full codebase you can run and study alongside the theory.
Why EF Core Returns Data From Memory, Not the Database
EF Core maintains an in-memory identity map inside every DbContext instance. When you load an entity by primary key, EF Core stores it in the change tracker. If you query for the same primary key again on the same DbContext instance, EF Core returns the in-memory object without issuing a second SQL SELECT — it assumes the object is still the freshest version it has.
This is by design. The identity map ensures object identity consistency within a single unit of work: two calls to FindAsync<Order>(1) on the same context return the same CLR object reference, not two independent copies. This is what allows EF Core's change tracker to detect modifications accurately and generate correct UPDATE statements.
The problem emerges when something modifies the underlying data outside the change tracker's awareness — and the same context keeps serving the stale in-memory copy as if nothing changed.
The Four Production Scenarios That Trigger Stale Reads
How Does ExecuteUpdate Cause Stale Read Results?
ExecuteUpdate and ExecuteDelete issue direct SQL statements that bypass the EF Core change tracker entirely. They are efficient precisely because they do not load entities into memory — but that efficiency has a direct consequence. Any entity you have already tracked in the same DbContext instance is not updated when the SQL executes.
If your code loads an order, calls ExecuteUpdate to change its status, and then reads the order through the same tracked reference or re-queries by the same primary key, the change tracker returns the old in-memory object. The SQL ran, the database row changed, but the context does not know.
What Happens When DbContext Is Not Scoped Per Request?
DbContext is designed to be a short-lived unit of work — created per request, disposed at the end. When a DbContext lives longer than a single request scope, its change tracker accumulates tracked entities across many operations. Entities loaded early persist in the identity map indefinitely. Later reads for the same primary key return the long-stale cached version rather than the current database state.
Most teams avoid the explicit singleton mistake, but it surfaces in less obvious ways: a background service that creates one DbContext at startup and reuses it, or a scoped service that is captured inside a singleton-scoped dependency. Scoped services captured by singletons cause this exact pattern without any deliberate singleton registration.
Why Does the Read-Update-Read Pattern Return Old Data?
A common write-path pattern: fetch an entity, modify it, save, then read it back to return to the caller. If the initial fetch and the final read both use the same DbContext instance — which is typical within a single request scope — the final read returns the tracked in-memory entity, not a fresh query result.
For simple scalar property updates this may produce the correct value. For changes involving database-generated defaults, computed columns, triggers, or navigation properties modified by the write, the in-memory object will not reflect what the database actually stored after the commit.
How Do Multiple Services Sharing One DbContext Cause Data Races?
In complex request handlers that call multiple services, or in pipelines where middleware and controllers touch the same DbContext, the implicit assumption is that no other code path has modified a tracked entity between the first load and the final read. That assumption does not hold in concurrent systems. Service A reads and caches an entity; an external process or a concurrent request modifies the row; Service A still serves the original cached version until the DbContext is disposed.
How to Diagnose Stale Data in Production
The most reliable diagnostic is SQL query logging. Enable LogLevel.Information for EF Core's Microsoft.EntityFrameworkCore.Database.Command category in your logging configuration and observe the output during a write-then-read sequence. A correct implementation produces two SELECT statements for the same primary key predicate — one for the initial load, one for the reload after the write. If you see an UPDATE followed by no SELECT, EF Core returned the entity from the change tracker without querying the database.
For production diagnostics, OpenTelemetry traces on database commands reveal the same pattern without surfacing sensitive SQL in logs. A span for an expected SELECT that does not appear is the signal you are looking for. The EF Core Loading Strategies guide covers how to interpret query activity to determine when reads actually reach the database versus when they are identity map hits.
Applying AsNoTracking() to the suspect query and confirming a SQL round trip in the logs is the fastest way to verify the diagnosis.
The Correct Fix for Each Scenario
Fix 1: Default to AsNoTracking for All Read-Only Queries
For any query where you do not intend to modify the result within the same DbContext lifetime, chain AsNoTracking(). EF Core will not register the returned entity in the identity map. Every subsequent read for that entity issues a fresh SQL SELECT and materialises a new CLR object — you always read the current database state.
This should be the default for list endpoints, GET-by-id read models, and any query that feeds a response DTO. The performance benefit is secondary to the correctness guarantee: a read query that does not track cannot serve stale data from the identity map.
When you need to track an entity for a write operation but want to read its post-save state — particularly for database-generated values, triggers, or computed columns — call Entry(entity).ReloadAsync(cancellationToken) immediately after SaveChangesAsync. This forces EF Core to issue a fresh SELECT by primary key and overwrite the in-memory instance with the current database state, while keeping the entity tracked for any further modifications in the same scope.
This is the right approach when the write path genuinely requires tracking and a second full DbContext scope would be wasteful.
Fix 3: Create a New DbContext Scope for the Post-Write Read
After a write completes, create a new DbContext instance via a new DI scope and read from it. The fresh context has an empty identity map — there is no tracked entity to return, so EF Core must query the database. This is the most resilient approach for patterns where write and read concerns are logically separated.
CQRS-oriented designs lean toward this naturally: commands own one scope, queries own another. When a command completes and a confirmation read is required, issuing that read through a fresh IServiceScopeFactory-created scope eliminates the entire class of stale identity-map problems.
Fix 4: Project Directly to a DTO With Select()
If you are reading after a write to produce a response object, project the query to a DTO using Select() rather than materialising the full tracked entity. A projection query always issues a fresh SQL SELECT — even if an entity with the same primary key is currently tracked — because EF Core executes the projection as a raw column-level query and does not look up the identity map for the projected DTO type.
This also reduces data transfer by selecting only the columns the response requires, which benefits high-traffic read paths independently of the stale-data fix.
How to Prevent Stale Data From Reaching Production
The most effective prevention is a team-level default: all read queries use AsNoTracking() unless the entity will be modified within the same DbContext lifetime. This single convention removes the majority of stale-data scenarios without requiring per-case analysis.
Enforce DbContext lifetime rules through architecture tests or DI registration audits. Verify that DbContext registrations use AddDbContext (scoped), that no derived DbContext subclass has been accidentally registered as a singleton, and that no scoped service resolves a DbContext from a captured singleton dependency. Catching this at build time or in CI eliminates a family of runtime bugs before they reach production.
Include at least one integration test for every write-then-read sequence in your critical paths. The test should assert that the value returned by the GET after a PATCH reflects the updated database state — not the in-memory pre-update value. If the test uses separate DbContext instances across the write and the read, it reliably catches the scenario.
FAQ
Why does AsNoTracking fix the stale data problem in EF Core?
AsNoTracking() instructs EF Core not to register the returned entity in the identity map. Without a tracked entry for that primary key, there is no in-memory object to return. Every query with AsNoTracking() issues a fresh SQL SELECT and creates a new CLR object, which always reflects the current database state at the time of the query.
Does EF Core stale data only occur within a single HTTP request?
No. If a DbContext lives longer than a single request — which is the case with singleton registrations, static context wrappers, or background services that hold a single long-lived context — the identity map accumulates entries across requests. A later request can receive data that was originally loaded and cached during an earlier request, even if the database row has since been modified and committed by another operation.
What is the difference between Entry(entity).ReloadAsync() and querying with AsNoTracking()?
ReloadAsync() operates on an entity that is already tracked in the identity map — it issues a fresh SELECT by primary key and overwrites the tracked instance with the latest database values, keeping the entity in the change tracker. An AsNoTracking() query creates a new, untracked CLR object with no connection to the change tracker at all. Use ReloadAsync() when you need to continue tracking the entity after refreshing its values; use AsNoTracking() when you only need the current values for reading or returning in a response.
Does AddDbContextPool make stale data worse?
The built-in AddDbContextPool implementation resets the change tracker when a context is returned to the pool, so pooled contexts do not persist tracked entities across pools borders under normal usage. However, if your DbContext subclass carries additional instance state beyond EF Core's own change tracker — and you do not override ResetState() or ResetStateAsync() to reset it — that state will survive pool recycling and can produce unexpected behaviour including stale data from your own caches.
What happens to EF Core global query filters when data is served from the identity map?
Global query filters, such as soft-delete exclusions (IsDeleted == false), are evaluated at query execution time, not at entity retrieval time from the identity map. When EF Core returns an entity directly from the identity map without issuing a SQL query, global filters are not re-evaluated. A soft-deleted entity that was loaded into the identity map before its deletion will be returned from cache even after it would be excluded by a fresh filtered query. This is a strong additional reason to use AsNoTracking() for read models and to re-query in a new scope for any read that follows a write affecting filter-relevant fields.
