EF Core from zero to production: lessons from production

EF Core from zero to production: The setup that scales

Over my 5+ years building production platforms, I've learned that Entity Framework Core success isn't about chasing every feature—it's about establishing patterns early that prevent pain later. EF Core from zero to production means making deliberate choices around context design, configuration, pooling, and visibility before your codebase grows beyond your ability to refactor it cleanly. I want to share the exact setup I use on every new .NET project, from day one.

One DbContext per bounded context

The biggest mistake I see is a single, god-tier DbContext that owns every entity in your domain. It feels convenient when you're starting, but around 80–100 entities, it becomes a bottleneck: schema changes get slow, migrations balloon, and parallel feature work causes constant conflicts.

Instead, I design one DbContext per bounded context. If you're building an e-commerce platform, you might have OrderContext, CatalogContext, and PaymentContext. Each owns its slice of the domain and migrates independently.

Why this matters in production:

• Faster migrations. A change to the Order table doesn't require coordinating with Catalog team work.
• Focused models. Your DbContext has 15 entities, not 150. You understand the relationships at a glance.
• Parallel deployment. Different bounded contexts can deploy on different schedules if needed.

On a ride-hailing platform I worked on, we had separate contexts for Rides, Payments, and Driver Management. When the Payments team needed to add ledger tables, the Rides context wasn't touched—no risk, no merge conflicts, no regression testing other features.

// Example: OrderContext
public class OrderContext : DbContext
{
    public OrderContext(DbContextOptions<OrderContext> options) 
        : base(options) { }

    public DbSet<Order> Orders { get; set; }
    public DbSet<OrderItem> OrderItems { get; set; }
    public DbSet<OrderShipment> Shipments { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.ApplyConfigurationsFromAssembly(typeof(OrderContext).Assembly);
    }
}

Configure with IEntityTypeConfiguration

Putting all your Fluent API mapping logic inside OnModelCreating turns the method into a wall of text. After a dozen entities, you can't find anything. Instead, use IEntityTypeConfiguration<T> to isolate configuration per entity.

Each configuration class owns one entity and lives near it in your project structure. It's easier to test, easier to navigate, and easier to hand off to a teammate who's working on that specific table.

Here's how I structure it:

public class OrderConfiguration : IEntityTypeConfiguration<Order>
{
    public void Configure(EntityTypeBuilder<Order> builder)
    {
        // Primary key
        builder.HasKey(x => x.Id);

        // Decimal precision (critical for money)
        builder.Property(x => x.Total)
            .HasPrecision(18, 2)
            .IsRequired();

        builder.Property(x => x.SubTotal)
            .HasPrecision(18, 2)
            .IsRequired();

        // Indexes for queries
        builder.HasIndex(x => x.CustomerId);
        builder.HasIndex(x => x.OrderNumber).IsUnique();
        builder.HasIndex(x => new { x.CustomerId, x.CreatedAt });

        // Relationships
        builder.HasMany(x => x.Items)
            .WithOne(x => x.Order)
            .HasForeignKey(x => x.OrderId)
            .OnDelete(DeleteBehavior.Cascade);

        // Default values or value conversions
        builder.Property(x => x.Status)
            .HasDefaultValue(OrderStatus.Pending)
            .HasConversion<string>();

        builder.Property(x => x.CreatedAt)
            .HasDefaultValueSql("GETUTCDATE()");
    }
}

Notice the decimal precision. I use HasPrecision(18, 2) for money fields—18 digits total, 2 after the decimal. SQL Server defaults to (18,0), which truncates cents. That's a production bug waiting to happen if you skip this.

On a trading platform I built, we had FeeConfiguration, TradeConfiguration, and CurrencyPairConfiguration—each one a small, focused file that a developer could understand in 30 seconds.

ApplyConfigurationsFromAssembly

Once you have separate configuration classes, you need to wire them into OnModelCreating. You could call builder.ApplyConfiguration(new OrderConfiguration()) 50 times, but that's tedious and error-prone—you'll forget one.

Instead, use ApplyConfigurationsFromAssembly. One line. It scans the assembly, finds every class implementing IEntityTypeConfiguration<T>, and applies it automatically.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // That's it. Picks up all configuration classes in this assembly.
    modelBuilder.ApplyConfigurationsFromAssembly(typeof(OrderContext).Assembly);
}

The benefit is scale: as you add new entities, their configurations are wired automatically. No forgetting to register them, no merge conflicts in OnModelCreating, no ceremony.

I've seen teams add 10, 20, 50 entities this way with zero additional complexity in the context setup.

Pool your contexts

DbContext instances are lightweight but not free. Allocating a new context on every request costs memory and CPU. In a hot API handling thousands of requests per second, this adds up.

Enter AddDbContextPool. Instead of creating and disposing a context per request, EF Core maintains a pool of reusable instances. When a request finishes, the context is cleared and returned to the pool. Next request grabs it from the pool instead of allocating fresh.

Setup is one line in your Startup or Program.cs:

services.AddDbContextPool<OrderContext>((serviceProvider, options) =>
{
    options.UseSqlServer(
        configuration.GetConnectionString("Orders"),
        sqlOptions => sqlOptions.CommandTimeout(30)
    );
});

Important caveat: pooling is safe only if you don't store context state in properties. Some teams add flags like IsAdmin to DbContext—those break pooling because the flag persists across requests. If you need request-scoped state, use dependency injection to pass it separately or use a separate service class.

On an e-commerce platform handling 500+ orders per minute, switching to pooling reduced our average allocation time by 40% and GC pressure noticeably dropped.

Log the SQL in development

The worst kind of production bug is when you think EF is executing one query but it's actually executing ten. You might be loading the entire Order with all related Items when you only need the total. Without visibility, you'll ship that and discover it in production metrics.

In development, enable sensitive data logging and wire EF's logs to your console. You'll see exactly what SQL gets generated and catch N+1 queries before they go live.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    if (env.IsDevelopment())
    {
        optionsBuilder
            .LogTo(Console.WriteLine, LogLevel.Information)
            .EnableSensitiveDataLogging();
    }
}

Sensitive data logging includes actual parameter values in the log, so you see WHERE CustomerId = 42 instead of WHERE CustomerId = @p1. This is crucial for debugging but absolutely do not enable it in production—it logs passwords, credit card numbers, and PII.

A better approach for production is to log to a structured logger (Serilog, Application Insights) and only log slow queries or specific diagnostic scenarios.

Common mistakes

Forgetting precision on decimal columns. SQL Server's default is NUMERIC(18,0). Use HasPrecision(18, 2) for money. Every. Time.

Over-indexing. Index every foreign key and common filter column, but don't create an index for every possible WHERE clause combination. Pick your hot paths via APM first.

Mixing DbContext and DbContextOptions configuration. Choose either fluent API in OnModelCreating or external configuration files, but not both scattered randomly. Consistency matters for maintainability.

Enabling sensitive data logging in production. It logs passwords. Don't do it.

Storing context state as properties. If you use pooling (which you should), don't add public bool IsAdmin { get; set; } to your context. That state persists across requests. Use a separate service or inject it via constructor parameters.

Key takeaways

• Design one DbContext per bounded context to keep models focused and migrations independent.
• Use IEntityTypeConfiguration<T> to keep mapping logic organized and testable.
• Call ApplyConfigurationsFromAssembly once in OnModelCreating to wire all configs automatically.
• Use AddDbContextPool to reduce allocation overhead on high-traffic APIs.
• Log SQL in development with EnableSensitiveDataLogging to catch N+1 and inefficient queries early; never enable in production.
• Always use HasPrecision(18, 2) on decimal columns used for money.