Decision Guide

Database client packages for .NET

Even when ORMs are used, direct ADO.NET clients remain a critical layer for connection behavior, resiliency, and diagnostics. Choose provider packages that match your engine roadmap and operational requirements.

5decision criteria

3packages compared

5pre-launch checks

The decision Shortlist Implementation plan Pitfalls & checklist When to revisit

The decision to make

Which database client package should your .NET service standardize on per engine?

Primary relational engines in production and migration plans for future engines.
Connection pooling, retry behavior and transport security defaults.
Support for async I/O, bulk operations and command timeout tuning.
Instrumentation and logging hooks for troubleshooting production issues.
Compatibility with your ORM, micro-ORM and migration tooling.

Shortlist & Trade-offs

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

Microsoft.Data.SqlClient

Modern SQL Server data provider for .NET with active support for SQL Server and Azure SQL scenarios.

Inspect package

Best fit: Workloads running on SQL Server family platforms that need current security and connectivity features.

Validate first: Provider behavior and defaults should be validated during major version upgrades.

Npgsql

High-quality PostgreSQL data provider for .NET with strong performance and PostgreSQL feature coverage.

Inspect package

Best fit: Applications standardized on PostgreSQL that need robust async support and observability integration.

Validate first: Provider-specific data type behaviors should be tested when porting from other engines.

MySqlConnector

Fully managed async-first MySQL connector widely used for MySQL and MariaDB workloads.

Inspect package

Best fit: Services requiring reliable async behavior and modern .NET compatibility with MySQL-family databases.

Validate first: Engine-version and server-configuration differences still require integration testing in realistic environments.

Practical implementation plan

1
Select one supported provider per engine and keep its version compatible with the runtime and ORM. Centralize connection setup, pool configuration, retries, and command timeout defaults.
2
Apply least-privilege database identities by workload. Separate application runtime permissions from migration and operational-admin permissions.
3
Instrument connection opens, command durations, timeout rates, and pool exhaustion. Investigate patterns with database-native monitoring and query plans, not application logs alone.

Risk

Common pitfalls

Giving the runtime application identity schema-owner or administrator rights because migrations are convenient during development.
Relying on provider defaults for TLS, pool size, retries, and timeout behavior without validating them against production load.
Creating a new connection string or client configuration per request, fragmenting pools and making incidents difficult to diagnose.

Checklist

Before production

Connections use encrypted transport and credentials are sourced from managed configuration.
Runtime and migration principals have separate least-privilege permissions.
Pool sizing, timeouts, and retries are load-tested against deployment concurrency.
Provider metrics and slow-query diagnostics are available to operations.
Failover, rotation, and database maintenance behavior are tested or rehearsed.

When to revisit this choice

Revisit database client choices when changing cloud database offerings, introducing stronger compliance controls, or seeing recurring production connection incidents.