Tracking vs No-Tracking Queries Explained

Entity Framework provides an object-relational mapping layer that simplifies database access in .NET applications. One of its key features is change tracking, which allows Entity Framework to monitor entities retrieved from the database and automatically detect modifications when SaveChanges is called.

Although this behaviour is extremely useful, it is not always required. In many scenarios, particularly when displaying data that will not be modified, tracking entities can introduce unnecessary overhead. Understanding the difference between tracking and no-tracking queries helps developers build more efficient applications.

What Is a Tracking Query?

A tracking query is the default behaviour in Entity Framework. When entities are loaded from the database, the DbContext stores information about them in its change tracker.

This allows Entity Framework to determine what has changed since the entity was loaded. When SaveChanges is called, only the modified properties are included in the generated SQL statements.

For example, the following query returns tracked entities:

var products = context.Products.ToList();

If one of the returned Product objects is modified, Entity Framework will automatically detect the change and persist it to the database when SaveChanges is executed.

Tracking queries are particularly useful when data is being edited within the same DbContext instance because no additional work is required to update the entity state.

How Change Tracking Works

When an entity is materialised from a tracking query, Entity Framework stores a snapshot of its original values. As properties are modified, the framework compares the current values against the original snapshot.

This process allows Entity Framework to identify inserts, updates and deletes without the developer having to manually specify what has changed.

The change tracker also ensures that if the same entity is retrieved multiple times during the lifetime of the DbContext, the same object instance is returned. This behaviour is known as identity resolution and helps maintain consistency across the application.

The Cost of Tracking

Although change tracking is convenient, it comes with a cost. Every tracked entity consumes memory and requires additional processing by the DbContext.

In applications that retrieve large numbers of records for reporting, dashboards or read-only screens, this overhead can become significant. The more entities that are tracked, the more work Entity Framework must perform to manage them.

This can lead to increased memory consumption and slower query execution, especially in high-traffic web applications.

What Is a No-Tracking Query?

A no-tracking query tells Entity Framework not to store the returned entities in the change tracker.

This is achieved by using the AsNoTracking method:

var products = context.Products

.AsNoTracking()

.ToList();

The returned entities behave like ordinary objects but are not monitored for changes. If modifications are made to them, Entity Framework will not automatically save those changes.

Because no tracking information needs to be maintained, these queries are generally faster and use less memory than standard tracking queries.

When to Use No-Tracking Queries

No-tracking queries are ideal when data is only being displayed and there is no intention to update it.

Common examples include product listings, reporting screens, dashboards, search results and public-facing websites where large amounts of data are retrieved and displayed.

In these scenarios, using AsNoTracking can provide measurable performance improvements, particularly when working with thousands of records.

Many developers choose to make no-tracking the default behaviour for read-only repositories to maximise efficiency.

Tracking vs No-Tracking Performance

The performance difference between tracking and no-tracking queries depends on the volume of data being retrieved and the complexity of the entities involved.

For small result sets the difference may be negligible. However, as the number of records increases, the overhead of maintaining tracking information becomes more apparent.

Benchmarks frequently show lower memory usage and faster execution times when AsNoTracking is used for read-only operations. The exact improvement varies depending on the application and database workload.

Using AsNoTrackingWithIdentityResolution

Entity Framework Core introduced AsNoTrackingWithIdentityResolution as a middle ground between full tracking and standard no-tracking queries.

This option does not track entities for updates, but it does ensure that duplicate references to the same entity are represented by a single object instance.

For complex queries involving relationships and joins, this can reduce memory consumption while maintaining consistency within the result set.

An example is shown below:

var products = context.Products

.AsNoTrackingWithIdentityResolution()

.ToList();

This feature is particularly useful when loading large object graphs that contain repeated references to the same entities.

Choosing the Right Approach

The decision between tracking and no-tracking queries should be based on how the data will be used.

If the data will be modified and saved back to the database within the same DbContext, tracking is the correct choice. The change tracker simplifies updates and reduces the amount of manual coding required.

If the data is being displayed for informational purposes only, no-tracking queries are generally the better option. They reduce memory usage, improve query performance and allow applications to scale more effectively.

Many modern applications use a combination of both approaches, selecting the most appropriate option based on the requirements of each query.

Conclusion

Tracking and no-tracking queries are fundamental concepts in Entity Framework that can have a significant impact on application performance. Tracking queries provide automatic change detection and simplify updates, while no-tracking queries offer better performance for read-only operations. By understanding the strengths of each approach and applying them appropriately, developers can create applications that are both efficient and maintainable.