MySqlConnector for .NET: A Managed ADO.NET Provider for MySQL and MariaDB

What MySqlConnector Solves in Managed .NET Applications

MySqlConnector provides the ADO.NET classes that a managed .NET application needs to communicate with MySQL and compatible servers. According to the README, those implementations include `DbConnection`, `DbCommand`, `DbDataReader`, and `DbTransaction`. This makes it relevant to applications that execute SQL directly, use lower-level data access APIs, or rely on libraries built on top of ADO.NET rather than requiring a complete ORM. The project is written primarily in C# and describes itself as a clean-room implementation of the MySQL protocol, not as a wrapper around Oracle's Connector/NET.

The target audience includes developers working across the .NET Framework and .NET Core platforms supported by the project. The README lists Dapper, FreeSql, Gedaq, LINQ to DB, MuchAdo, NHibernate, NReco.Data, and SimpleStack.Orm as compatible projects. Entity Framework is handled through the separate Pomelo.EntityFrameworkCore.MySql package, so MySqlConnector itself should not be treated as an Entity Framework provider. ASP.NET Core health checks are also handled by a separate project, AspNetCore.HealthChecks.MySql.

This separation is a design decision rather than a missing convenience. The project says it implements the core of ADO.NET and does not include EF or Designer types. That scope can reduce the amount of database API an application has to carry, but it also means that code needing broader Connector/NET compatibility may require review before migration.

MySqlConnector's ADO.NET and MySQL Protocol Design

The project sits between managed .NET database calls and the MySQL wire protocol. Its public role is conventional ADO.NET: callers work with connection, command, reader, and transaction abstractions, while the provider handles communication with the selected server. The README describes the implementation as independent and managed, with no native code. That architecture is relevant on teams that want to avoid a native dependency, although the README does not claim that managed code removes every deployment or compatibility concern.

The project states that all operations should be genuinely asynchronous whenever possible. The README also identifies support for newer ADO.NET APIs, including async, `DbBatch` from .NET 6.0, and `DbDataSource` from .NET 7.0. These features are not separate products. They indicate that the provider tracks the ADO.NET surface used by newer .NET applications while remaining usable by older supported frameworks.

MySqlConnector is described as compatible with many MySQL-compatible servers, including MySQL 5.5 and newer and MariaDB 10.x and newer. The README contrasts this with MySql.Data, which it says only supports MySQL Server. That distinction matters when the application must connect to MariaDB or another compatible server. The README does not document connection-string syntax, supported authentication methods, TLS configuration, pooling behavior, or error handling details, so those points cannot be assumed from this repository summary.

Installation, Build, and Integration Test Setup

The README directs users to install the latest .NET, clone the repository, and run the restore and test commands for the main test project. These commands build and test the repository rather than demonstrate a separate application installation. The first command restores the project's NuGet dependencies, and the second runs the test project named in the README.

To build and run the tests, execute:

dotnet restore
dotnet test tests\MySqlConnector.Tests

The README says that integration tests have separate instructions in `tests/README.md`. It does not provide a connection example, package-add command, connection string, or sample application. For that reason, a first real application use cannot be shown without inventing configuration. The repository's documented first use is the test build and test run, while the integration test setup should be read from `tests/README.md`.

MySqlConnector is distributed through NuGet under `MySqlConnector`, as shown by the README's NuGet badge and links. The README does not state the exact installation command or a version-specific package reference, so this review does not add one. A NuGet installation would normally be the path for consuming the package in an application, but the README does not document that command here.

Server Compatibility and Deliberate Scope Limits

The clearest use case is a .NET application that needs direct database access to MySQL or MariaDB and values a provider built around ADO.NET. The README states compatibility with MySQL 5.5 and newer and MariaDB 10.x and newer, plus other compatible servers. It also says the provider tracks recent ADO.NET APIs, which may matter for applications using `DbBatch` or `DbDataSource`.

The limitation is equally concrete. MySqlConnector is not a complete replacement for every Connector/Net feature. The README explicitly says that cloning the full API of Connector/NET is not a goal, although the project tries to avoid gratuitous incompatibility. An application that depends on Oracle-specific classes, designer surfaces, or an API outside the supported ADO.NET subset may need code changes. The project's migration documentation is linked as the place to investigate typical migration scenarios, but the README does not enumerate every incompatible type.

Entity Framework users need a different package. The README directs them to Pomelo.EntityFrameworkCore.MySql. Health-check integrations are also external through AspNetCore.HealthChecks.MySql. These boundaries make MySqlConnector less convenient for teams seeking one package that covers ORM, health checks, and raw ADO.NET. They also make its ownership clearer.

MySqlConnector Compared with MySql.Data

The most direct alternative named by the README is MySql.Data, also called MySQL Connector/NET. The documented difference is server coverage. MySqlConnector says it supports MySQL and other compatible servers, including MariaDB, while MySql.Data is described as supporting only MySQL Server. That makes the choice significant for applications that must use MariaDB.

The second difference is API scope. MySqlConnector intentionally implements the core ADO.NET classes and newer ADO.NET APIs, but it does not aim to clone the entire Connector/NET API. MySql.Data is therefore the more relevant candidate when an existing application depends on Oracle-specific Connector/NET features. The README also links a migration tutorial and a list of fixed bugs, but it does not claim that every migration is automatic.

For ORM use, the alternative is not another raw provider. The README names Pomelo.EntityFrameworkCore.MySql for Entity Framework support. That package provides a different layer around database access. A team choosing between MySqlConnector and Pomelo should first determine whether it needs direct ADO.NET calls or Entity Framework abstractions, rather than comparing them as interchangeable installs.

Maintenance, Releases, and the MIT License

The repository is not archived. Its last push was on 2026-10-14, and the recent releases listed are 2.6.2 on 2026-08-11, 2.6.1 on 2026-06-25, and 2.6.0 on 2026-06-02. This indicates recent release activity in the repository record, but the README does not describe a support policy, long-term support branch, migration guide for each release, or compatibility matrix beyond the server versions listed.

The license is MIT. The README says the library may be freely distributed with commercial software and separately notes that commercial software using Connector/NET may have to purchase a commercial license from Oracle. That distinction matters during migration: changing data providers can affect licensing obligations as well as code compatibility. This is a factual reading of the README's licensing note, not legal advice.

The upgrade cost depends on the application surface. Applications limited to the ADO.NET classes documented here have a smaller migration surface than applications using the full MySql.Data API. The repository provides a migration tutorial link, but the README does not document the exact breaking changes between releases.

Editorial conclusion

Adopt MySqlConnector when a .NET application needs a lightweight managed ADO.NET provider and can work within its documented server and API boundaries. Do not choose it for an application that requires the full MySql.Data API, Entity Framework, or designer types. Verify the target server, the required ADO.NET surface, and the integration test setup before committing to a migration.

Frequently asked questions

Official sources

1. License: MIT
2. mysql-net/MySqlConnector on GitHub
3. Project website
4. README
5. Releases