𝗧𝗵𝗶𝘀 𝗹𝗶𝘁𝘁𝗹𝗲 𝘁𝗿𝗶𝗰𝗸 𝘁𝗼𝗼𝗸 𝗺𝘆 𝗘𝗙 𝗖𝗼𝗿𝗲 𝗾𝘂𝗲𝗿𝘆 𝗳𝗿𝗼𝗺 𝟭𝟬 𝘀𝗲𝗰𝗼𝗻𝗱𝘀 𝘁𝗼 𝟰𝟬 𝗺𝗶𝗹𝗹𝗶𝘀𝗲𝗰𝗼𝗻𝗱𝘀 And I didn't use AI for this (it sucked!) AI wrote the same EF Core mistakes I see in code reviews: ❌ Projecting data in memory after ToListAsync ❌ Making too many database requests ❌ Loading full entities to show 4 columns In development, these queries run in a few milliseconds. But at 2 million rows in production, the same endpoint takes 30 seconds. Your integration tests won't catch it. 👉 The trick: project only the columns you need with .Select() ↳ The database reads less data ↳ Less data goes over the network ↳ No change tracking at all That's 1 of 13 fixes. Here they all are, in the order I apply them 👇 𝗦𝘁𝗲𝗽 𝟬: 𝗠𝗲𝗮𝘀𝘂𝗿𝗲 𝗳𝗶𝗿𝘀𝘁 ↳ Log the SQL with LogTo and run EXPLAIN ANALYZE 𝗦𝘁𝗲𝗽 𝟭: 𝗙𝗲𝘁𝗰𝗵 𝗹𝗲𝘀𝘀 𝗱𝗮𝘁𝗮 ↳ Add indexes for columns you filter and sort on ↳ Filter with Where() before ToListAsync ↳ Project only the columns you need 𝗦𝘁𝗲𝗽 𝟮: 𝗟𝗼𝗮𝗱 𝗱𝗮𝘁𝗮 𝗰𝗼𝗿𝗿𝗲𝗰𝘁𝗹𝘆 ↳ AsNoTracking for read-only queries ↳ Include only what you need, no lazy loading ↳ AsSplitQuery for multiple collections (measure first) 𝗦𝘁𝗲𝗽 𝟯: 𝗦𝗰𝗮𝗹𝗲 𝘄𝗶𝘁𝗵 𝘆𝗼𝘂𝗿 𝗱𝗮𝘁𝗮 ↳ Cursor pagination for deep pages (Skip/Take crawls at page 5,000) ↳ Batch huge Contains() ID lists before they hit DB limits 𝗦𝘁𝗲𝗽 𝟰: 𝗦𝘁𝗼𝗽 𝗿𝗲𝗽𝗲𝗮𝘁𝗶𝗻𝗴 𝘄𝗼𝗿𝗸 ↳ Compiled queries for hot paths ↳ Cache the result 𝗦𝘁𝗲𝗽 𝟱: 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗲 𝘄𝗿𝗶𝘁𝗲𝘀 ↳ Call SaveChanges once, outside the loop ↳ ExecuteUpdate and ExecuteDelete for bulk changes ↳ DbContextFactory in background services Don't add caching to hide your slow database queries. You are only fixing the symptoms. First fix your database queries and only after that add caching to make it even faster and to increase your application throughput. 📌 I wrote a step-by-step guide with code for all 13 performance improvements in EF Core: ↳ antondevtips.com/blog/ef-cor… Which of these 13 did you (or your agent) skip in your last project?