ToList() or ToArray()?
Both execute your query and materialize the results. So which should you reach for — and does the choice actually matter?
Both ToList() and ToArray() force execution of a deferred LINQ query and pull the results into memory. The question isn't which one 'runs the query' — they both do. It's what you do with the result afterward.
Reach for ToList() when the collection grows or changes
var items = await _db.Products
.Where(p => p.IsActive)
.ToListAsync();
items.Add(newProduct); // List<T> supports add/remove
items.RemoveAt(0);List<T> is the right default for most application code: it's flexible, supports Add/Remove, and is what most APIs expect. In EF Core, ToListAsync() is the idiomatic materialization call.
Reach for ToArray() for fixed, read-only sets
var ids = await _db.Orders
.Select(o => o.Id)
.ToArrayAsync();
// Fixed size, read-only iteration, minimal overheadRule of thumb: ToList() when the collection will change; ToArray() when it's a fixed, read-only snapshot.
The difference is rarely a performance bottleneck on its own — the real cost is materializing more rows than you need. Project with Select, filter in the database, and only then decide on List vs Array. Shape the query first; pick the container second.
Muhammad Zain
Senior Application Engineer
Keep reading
.Result Will Deadlock Your API
After years of reviewing .NET production incidents, one anti-pattern keeps showing up in the same place — blocking on async code with .Result or .Wait().
Clean Architecture That Actually Scales
Clean Architecture isn't about folders named 'Domain' and 'Application'. It's about which way your dependencies point — and why that pays off the day the business grows.