Skip to main content
N
About

Decision guide

Entity Framework Core packages

Entity Framework Core is a platform plus provider model. The most important decision is not only using EF Core, but selecting the provider and tooling combination that matches your SQL dialect, migration discipline and performance envelope.

5 criteria3 packages5-point checklist

The decision to make

Which EF Core provider and tooling stack fits the database platform you operate?

  • Primary database platform and compatibility requirements across development, staging and production.
  • Migration workflow needs: design-time tools, bundles, SQL script review and zero-downtime rollout constraints.
  • Provider-specific translation quality for LINQ, JSON columns, array types and full-text search.
  • Operational needs for resiliency policies, connection pooling and transient-fault handling.
  • Ecosystem maturity for diagnostics, interception and community support.

Shortlist and trade-offs

These options are starting points, not an exhaustive market list. Verify the current release, compatibility, license and advisory information for your project on the linked package pages.

1

Microsoft.EntityFrameworkCore.SqlServer

EF Core provider for SQL Server with broad feature support and deep integration with Microsoft data tooling.

Inspect package
Best fit
Workloads standardized on SQL Server or Azure SQL that need mature migrations and provider documentation.
Validate first
Ties query behavior and advanced feature usage to SQL Server semantics and version capabilities.
2

Npgsql.EntityFrameworkCore.PostgreSQL

EF Core provider for PostgreSQL with strong support for PostgreSQL-specific capabilities.

Inspect package
Best fit
Teams using PostgreSQL features such as JSONB, arrays or advanced indexing patterns.
Validate first
Provider-specific behavior and SQL translation should be validated when porting from SQL Server-centric models.
3

Pomelo.EntityFrameworkCore.MySql

Community-driven EF Core provider for MySQL and compatible engines.

Inspect package
Best fit
Applications targeting MySQL or MariaDB that still want EF Core migrations and LINQ model ergonomics.
Validate first
Feature parity and translation details vary by engine version and should be verified with integration tests.

Practical implementation plan

  1. 1Pin all Microsoft.EntityFrameworkCore packages and the selected provider to the same major and minor version. Add the provider through the application's composition root, then enable detailed errors only outside production.
  2. 2Model one bounded context at a time. Use migrations as reviewed source files, generate a deployment script or bundle in CI, and apply schema changes through the release process instead of at application startup.
  3. 3Measure real queries before optimizing. Project only required columns, use no-tracking queries for reads, paginate deterministically, and inspect generated SQL plus execution plans for expensive endpoints.

Common pitfalls

  • Using the EF Core InMemory provider as evidence that relational queries and constraints work; use the production engine in integration tests instead.
  • Returning tracked entities directly from API endpoints, which can expose accidental navigations and create unnecessary change-tracking overhead.
  • Applying migrations automatically from every scaled-out application instance, creating rollout races and reducing deployment control.

Before production

  • Provider, EF Core runtime, design-time tools, and migrations are version-aligned.
  • The migration has been reviewed against a production-sized copy or representative schema.
  • Critical read paths have query-count and execution-plan checks.
  • Connection retries and command timeouts fit the database platform's guidance.
  • Backup, rollback, and backwards-compatibility steps are documented for destructive changes.

When to revisit this choice

Re-evaluate EF Core package strategy when changing database engines, adopting advanced provider features, or introducing stricter migration governance.

Data, method and limits

Sources: the public NuGet v3 registry and NuBrowse editorial review. Refresh: package pages read current registry metadata when viewed; guide text is revised separately. Method: the shortlist favours distinct use cases and spells out trade-offs instead of calculating a quality score. Limit: validate the specific version, license, framework and operational requirements in your project.