How to Scaffold Specific Tables in EF Core for a Faster DbContext

The problem: one giant DbContext for the whole database

Enterprise databases are big. It is common to find a shared SQL Server database with hundreds of tables serving many applications. When you reverse engineer that database into Entity Framework Core and generate a class for every table, you end up with one enormous DbContext that knows about the entire schema - even though any given service typically reads and writes only a small handful of tables.

That is convenient to generate, but it is the wrong shape for modern applications. A 500-entity context is slower to initialise, heavier in memory, and noisier to work with than a focused context that contains only what the project actually uses.

Scaffolding a subset with the built-in -Tables flag

EF Core's built-in Scaffold-DbContext can limit what it generates with the -Tables option. From the Visual Studio Package Manager Console:

Scaffold-DbContext "Server=.;Database=Northwind;Trusted_Connection=True;TrustServerCertificate=True" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models -Tables Order,OrderLine,Customer,Product

Or with the .NET CLI:

dotnet ef dbcontext scaffold "Server=.;Database=Northwind;Trusted_Connection=True;TrustServerCertificate=True" Microsoft.EntityFrameworkCore.SqlServer -o Models -t Order -t OrderLine -t Customer -t Product

That works for a few tables, but it does not scale well in practice:

• You must list every table by name. There is no pattern matching, so selecting 40 of 500 tables means typing 40 names - and updating that list by hand as the schema changes.
• There is no exclude. You can only opt tables in, not filter noisy audit, log or billing tables out.
• No column-level or schema-level control. It is tables and views only.
• Re-running overwrites your customisations, so keeping a curated subset in sync is painful.

The hidden cost: a big model is slow to start

Entity Framework builds its model the first time a DbContext is used. Every table, column, key and relationship has to be discovered and compiled into the model before a single query can run, and that one-off cost scales with the number of entities. The bigger the context, the longer that first use takes - and the more memory the finished model occupies for the lifetime of the process.

This is not a small effect. We measured the time to initialise the DbContext (the model build on first use) for two contexts generated from the same database:

The focused 4-table context started roughly 26 times faster than the 500-table one. In a long-running monolith you pay that cost once at startup and move on. In microservices, AWS Lambda and Azure Functions it hurts on every cold start: a service that only needs four tables should not be paying an eleven-second model-build tax to stand up the entire 500-table schema it never touches.

Filtering: generate only the tables you need

The EntityFramework Reverse POCO Generator solves the subsetting problem properly. Instead of naming tables one by one, you filter the schema with regular expressions - including and excluding tables, views, columns, stored procedures and functions - so each project generates exactly the model it needs. Filtering is configured in the generator's .tt file:

FilterSettings.Reset();
FilterSettings.AddDefaults();

// Only include the schemas this service cares about
FilterSettings.SchemaFilters.Add(new RegexIncludeFilter("^dbo$|^events$"));

// Include only the handful of tables the service actually uses
FilterSettings.TableFilters.Add(new RegexIncludeFilter("^Order$|^OrderLine$|^Customer$|^Product$"));

// ...or keep everything except the noisy audit/billing tables
FilterSettings.TableFilters.Add(new RegexExcludeFilter(".*[Bb]illing.*"));

The same include/exclude approach works at the column and stored-procedure level, giving you fine-grained control the built-in scaffolder simply does not offer:

// Drop columns you never map
FilterSettings.ColumnFilters.Add(new RegexExcludeFilter("^Internal_.*$"));

// Generate only the pricing stored procedures as strongly-typed calls
FilterSettings.StoredProcedureFilters.Add(new RegexIncludeFilter("Pricing.*"));

Because the filter is a pattern rather than a hand-typed list, it keeps working as the schema grows: new tables that match your rules are picked up (or excluded) automatically the next time you regenerate.

A lean DbContext per microservice

This is where filtering pays off most. In a microservices architecture, several services often sit over the same shared database, but each one owns a small slice of it. Rather than sharing one 500-table context, generate a purpose-built DbContext per service containing only that service's tables.

The generator can even produce multiple database contexts in a single pass, so you can maintain several lean, service-specific contexts from one place.

Step-by-step

1. Install the extension from the Visual Studio Marketplace.
2. Add the template to the project that needs the data layer (Add → New Item → EntityFramework Reverse POCO Generator).
3. Point it at your database by setting the connection string.
4. Add your filters. Use RegexIncludeFilter / RegexExcludeFilter on the schema, table, column and stored-procedure filters to narrow the schema to just this service's tables.
5. Save the .tt file to generate a lean DbContext, POCO entities, mappings and an optional FakeDbContext for testing.
6. Repeat per service - each gets its own small, fast context over the shared database.

The full set of filter options is documented in the Filtering page of the project wiki.

Frequently asked questions

How do I scaffold only specific tables in EF Core?

The built-in Scaffold-DbContext command accepts a -Tables (or -t) option where you list each table by name. For anything beyond a few tables, a dedicated tool such as the Reverse POCO Generator is easier: you filter tables, views and columns with regular expressions instead of maintaining a hand-typed list.

How do I exclude tables when scaffolding?

EF Core's built-in scaffolding only lets you include named tables; it has no exclude option. The Reverse POCO Generator supports both - add a RegexExcludeFilter to drop tables (for example audit, log or billing tables) by pattern while keeping everything else.

Why is my EF Core DbContext slow to start?

EF Core builds its model on first use, and that cost grows with the number of entities. A context covering hundreds of tables can take several seconds to initialise before any query runs. In our benchmark a 500-table context took 11.033 seconds versus 0.429 seconds for a 4-table context. Reducing the number of mapped entities is the most direct fix.

Can I have multiple DbContexts on the same database?

Yes. A common and recommended pattern - especially for microservices - is a small, focused DbContext per service over a shared database, each mapping only the tables that service needs.

Does a larger DbContext use more memory?

Yes. The compiled EF model holds metadata for every entity, property, key and relationship, and it stays in memory for the lifetime of the process. A context limited to the tables you actually use keeps that footprint small, which matters most in serverless and high-density container hosting.