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.

5decision criteria

3packages compared

5pre-launch checks

The decision Shortlist Implementation plan Pitfalls & checklist When to revisit

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 & Trade-offs

Curated starting points to compare. Always evaluate suitability against your specific project requirements.

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.

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.

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
Pin 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
Model 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
Measure 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.

Risk

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.

Checklist

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.