Database Performance

Solid fundamentals for keeping database queries fast in .NET applications. The read/write model separation is the big idea here: different DTOs for queries versus commands, AsNoTracking on reads, always paginate with limits. Shows you how to avoid N+1 queries with EF Core's Include or Dapper's multi-query, and hammers home the rule about doing joins in SQL instead of stitching data together in C#. Works with both EF Core and Dapper. This is the stuff that saves you when a feature works fine in dev with 100 rows but crawls in production with 100,000.

skills.sh installs: 700
GitHub stars: 1.3K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add aaronontheweb/dotnet-skills --skill database-performance --agent claude-code

Installs into .claude/skills of the current project.

Files

Database Performance Patterns

When to Use This Skill

Use this skill when:

Designing data access layers
Optimizing slow database queries
Choosing between EF Core and Dapper
Avoiding common performance pitfalls

Core Principles

Separate read and write models - Don't use the same types for both
Think in batches - Avoid N+1 queries
Only retrieve what you need - No SELECT *
Apply row limits - Always have a configurable Take/Limit
Do joins in SQL - Never in application code
AsNoTracking for reads - EF Core change tracking is expensive

Read/Write Model Separation (CQRS Pattern)

Read and write models are fundamentally different - they have different shapes, columns, and purposes. Don't create a single "User" entity and reuse it everywhere.

Read models are denormalized, optimized for query efficiency, and return multiple projection types (UserProfile, UserSummary, UserDetailForAdmin)
Write models are normalized, validation-focused, and accept strongly-typed commands (CreateUserCommand, UpdateUserCommand)