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

1. Separate read and write models - Don't use the same types for both
2. Think in batches - Avoid N+1 queries
3. Only retrieve what you need - No SELECT *
4. Apply row limits - Always have a configurable Take/Limit
5. Do joins in SQL - Never in application code
6. 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)

Architecture

src/
  MyApp.Data/
    Users/
      # Read side - multiple optimized projections
      IUserReadStore.cs
      PostgresUserReadStore.cs

      # Write side - command handlers
      IUserWriteStore.cs
      PostgresUserWriteStore.cs

      # Read DTOs - lightweight, denormalized
      UserProfile.cs
      UserSummary.cs

      # Write commands - validation-focused
      CreateUserCommand.cs
      UpdateUserCommand.cs
    Orders/
      IOrderReadStore.cs
      IOrderWriteStore.cs
      (similar structure...)

Read Store Interface

// Read models: Multiple specialized projections optimized for different use cases
public interface IUserReadStore
{
    // Returns detailed profile for single-user view
    Task<UserProfile?> GetByIdAsync(UserId id, CancellationToken ct = default);