RepoDB v1.16.0 — Nine New Database Providers, MySQL Bulk, and a Platform Shift
We are excited to announce RepoDB v1.16.0 — the first phase of RepoDB’s shift into a Data Movement Platform. This is the biggest release in the project’s history! 🔥
Previously, RepoDB supported SQL Server, PostgreSQL, MySQL, and SQLite. This release adds nine new database providers, including Bulk capabilities. It also introduces native Bulk operations for MySQL and MySqlConnector, plus a few intentional breaking changes to Core type conversion.
This release is more than provider expansion. It moves RepoDB beyond a hybrid ORM toward a developer-friendly data movement and connectivity platform. See the roadmap article for the broader direction.
🧩 The shape of this release
Each new provider follows a common structure: a core RepoDb.<Provider> package and a matching RepoDb.<Provider>.BulkOperations package. Each includes an IDbSetting, StatementBuilder, DbHelper, and provider-specific property handlers.
Most are early releases and not yet fully mature. Some have been implemented and reviewed but not fully tested against live instances. Review each provider’s limitations before production use.
⚡ How to work with the new RepoDB
Nine new providers mean nine new endpoints for moving data with the same programming model.
The key is IDataReader. BulkInsert accepts a data reader, allowing rows to stream from source to destination without loading the full dataset into memory. Connect ExecuteReader directly to BulkInsert to keep memory usage stable even for very large datasets.
using var source = new OracleConnection(oracleConnectionString);
source.Open();
using var sqlServer = new SqlConnection(sqlServerConnectionString);
using (var reader = source.ExecuteReader("SELECT * FROM Customer"))
sqlServer.BulkInsert<Customer>(reader, tableName: "Customer");
using var mariaDb = new MariaDbConnection(mariaDbConnectionString);
using (var reader = source.ExecuteReader("SELECT * FROM Customer"))
mariaDb.BulkInsert<Customer>(reader, tableName: "Customer");
An IDataReader is single-pass, so each destination needs its own ExecuteReader. Swap Oracle and SQL Server for any supported pair, and the code stays largely the same. That is the goal: one programming model across many databases.
Entity-based movement when filtering first
When you need only a subset of data, query it first and pass the entities to BulkInsert:
using var source = new OracleConnection(oracleConnectionString);
source.Open();
var activeCustomers = source.Query<Customer>(c =>
c.IsActive == true && c.CreatedDateUtc >= DateTime.UtcNow.AddYears(-1));
using var sqlServer = new SqlConnection(sqlServerConnectionString);
sqlServer.BulkInsert(activeCustomers);
The filter runs at the source, so only matching rows cross the wire. This approach materializes entities in memory, making it useful when you need to filter, inspect, or transform data. For very large unfiltered datasets, prefer the IDataReader streaming approach.
🌐 New database providers
Each provider includes a core package and a matching .BulkOperations package. Most are still early releases, so review their limitations before production use.
| Provider | Batch | Bulk | Sync | Async | Class | Versions supported |
|---|---|---|---|---|---|---|
| ClickHouse | ✅ | ✅ | ✅ | ✅ | ClickHouseBulkCopy / OPTIMIZE_ON_INSERT |
.NET 8/9/10 |
| DB2 | ✅ | ✅ | ✅ | ✅ | DB2BulkCopy Native (Sync) / Db2BulkArrayBinder (Async Native) | Db2 LUW 10.5+, .NET 8/9/10 |
| EnterpriseDB | ✅ | ✅ | ✅ | ✅ | EDBBulkCopy via RepoDb.Connector.EnterpriseDb / Npgsql Native |
EDB Postgres Advanced Server, .NET 8/10 |
| Firebird | ✅ | ✅ | ✅ | ✅ | FirebirdCommandBatcher via FbBatchCommand Native | Firebird 3.0+, .NET Standard 2.0, .NET 8/9/10 |
| MariaDB | ✅ | ✅ | ✅ | ✅ | MariaDbBulkCopy via RepoDb.Connector.MariaDb Native | .NET Standard 2.0, .NET 8/9/10 |
| MariaDB Connector | ✅ | ✅ | ✅ | ✅ | MariaDbBulkCopy via RepoDb.Connector.MariaDbConnector Native | .NET Standard 2.0, .NET 8/9/10 |
| Oracle | ✅ | ✅ | ✅ | ✅ | OracleBulkCopy Native / OracleBulkArrayBinder (Async Native) | Oracle 12c+, .NET 8/9/10 |
| SAP HANA | ✅ | ✅ | ✅ | ⚠️ | HanaBulkCopy Native (Sync) / Async over Sync or SapHanaCommandBatcher | .NET 8/9/10 |
| Vertica | ✅ | ✅ | ✅ | ⚠️ | VerticaBulkCopy via VerticaCopyStream / Async over Sync | .NET Standard 2.0, .NET 8/9/10 |
Install only one of
RepoDb.MariaDborRepoDb.MariaDbConnectorin a project. Both declare identically named types, so referencing both causes compile errors.
📦 New Bulk operations for MySQL and MySqlConnector
Two new packages add native Bulk operations for MySQL: BulkInsert, BulkMerge, BulkUpdate, BulkDelete, and BulkDeleteByKey, including async counterparts.
RepoDb.MySql.BulkOperations v1.0.0 targets MySqlConnection from MySql.Data. Because MySql.Data has no streaming bulk-copy API, RepoDB uses an internal MySqlBulkCopy built on MySqlBulkLoader and LOAD DATA LOCAL INFILE. It requires AllowLoadLocalInfile=True;AllowUserVariables=True; and the server’s local_infile setting enabled. The load runs outside the caller’s MySqlTransaction, so rollback does not undo an already completed BulkInsert.
RepoDb.MySqlConnector.BulkOperations v1.0.0 targets MySqlConnectorConnection. It adds MySqlConnectorBulkImportIdentityBehavior with Unspecified, KeepIdentity, and ReturnIdentity. Its bulk-load path also runs independently of the caller’s transaction. Use ReturnIdentity when you need the transactional array-bind path.
These packages have not yet been fully exercised against live MySQL environments. Validate bulk loading, identity handling, and staging behavior before production use.
💥 Breaking changes
This release introduces a small set of breaking changes needed for RepoDB’s next phase.
We minimized them where possible. Some could not be deprecated cleanly because of method and argument collisions.
Please review the changes before upgrading.
💥 Core (RepoDb v1.16.0)
Converter.ToType<T>() now handles null and DBNull more strictly. A null scalar result throws InvalidCastException unless automatic conversion is enabled, the target is a reference/by-ref type, or the target is System.Object.
Exists and ExistsAsync still return false when no match exists because they force automatic conversion.
This affects sync and async overloads of ExecuteScalar, Average, AverageAll, Count, CountAll, Exists, Max, MaxAll, Min, MinAll, and Sum.
The where argument is now required on Average, BatchQuery, Count, Max, Min, SkipQuery, and Sum across BaseRepository, DbRepository, and DbConnection extensions (#1266).
BaseDbSetting.AverageableType is now deprecated.
💥 RepoDb.MySql / RepoDb.MySqlConnector
MySqlBootstrap.Initialize() has been removed. Use GlobalConfiguration.Setup().UseMySql().
💥 RepoDb.PostgreSql
PostgreSqlBootstrap.Initialize() has been removed. Use GlobalConfiguration.Setup().UsePostgreSql().
RepoDb.PostgreSql.BulkOperations also standardizes several names:
NpgsqlBulkInsertMapItem→PostgreSqlBulkInsertMapItemBulkImportIdentityBehavior→PostgreSqlBulkImportIdentityBehaviorBulkImportMergeCommandType→PostgreSqlBulkImportMergeCommandTypeBulkImportPseudoTableType→PostgreSqlBulkImportPseudoTableTypeBinaryImport/BinaryBulkInsert/BinaryBulkMerge/BinaryBulkDelete/BinaryBulkDeleteByKey→ BulkInsert / BulkMerge / BulkDelete / BulkDeleteByKey
The old names remain as deprecated aliases, so existing code continues to compile while you migrate.
💥 RepoDb.SqlServer.BulkOperations
isReturnIdentity has been replaced by identityBehavior using SqlServerBulkImportIdentityBehavior in BulkInsert and BulkMerge. Replace boolean values with .ReturnIdentity or .Unspecified.
usePhysicalPseudoTempTable has been replaced by pseudoTableType using SqlServerBulkImportPseudoTableType across BulkInsert, BulkMerge, BulkUpdate, and BulkDelete. Replace boolean values with .Physical or .Temporary.
The primary-key overload of BulkDelete is now BulkDeleteByKey. Update calls that pass primary-key lists.
A new SqlServerBulkInsertMapItem adds the same column-mapping model used by PostgreSQL and Oracle. The base BulkInsertMapItem remains supported.
🟡 Cross-cutting, non-breaking: new IDbSetting extensibility
Core adds six non-breaking IDbSetting extensibility points:
RequiresDbTypeBeforeValue— setsDbTypebefore parameterValue.SkipsUnreferencedParameters— ignores parameters not referenced by generated SQL.MaxParameterCount— limits parameters per command. Default: 2,098; Firebird and Vertica: 1,500.MultiStatementSeparator— controls separators used by QueryMultiple andQueryMultipleAsync.SqlTextParameterPrefix— defines the parameter prefix for raw SQL.IsTransactionSupported— declares whether the driver supports transactions.
These settings keep provider-specific behavior out of Core. For example, Vertica can define parameter-binding order while Firebird can define a lower parameter limit.
⚠️ Limitations identified
Known limitations include composite keys, auto-generated primary columns, computed columns, JOIN queries, cache invalidation, advanced query-tree expressions, multiple identity columns, and SQL Server Bulk-specific cases. See LIMITATIONS.md for details.
🏢 Enterprise readiness
This release also clarifies RepoDB’s commitments for organizations evaluating it for production.
Benchmarks. Open, reproducible BenchmarkDotNet-based benchmarks compare RepoDB with Dapper, Entity Framework Core, Linq2Db, and NHibernate across CRUD, Batch, and Bulk workloads. They are available in src/Benchmarks. Clone and run them on your own infrastructure for the most relevant results. All nine new providers have dedicated benchmark projects.
Security. RepoDB’s Security Policy clearly documents its single-maintainer model and lack of an enterprise SLA. Security fixes target the latest published package versions, without backports. Vulnerabilities should be reported privately. The policy also documents key risks around raw SQL, credentials, provider internals, and third-party dependencies.
Packages. PACKAGES.md tracks Core, providers, Bulk packages, Telemetry, NuGet versions, downloads, and CI status. It now lists 14 provider packages and 14 matching Bulk packages, up from five each.
Contributing. CONTRIBUTING.md explains how to contribute code, report bugs, propose features, and improve documentation. New source files require copyright headers, while existing attribution remains unchanged when files are modified. RepoDB remains free and open source under Apache-2.0.
Caveats. RepoDB has no formal governance or enterprise SLA today. Only the latest release receives fixes. Pin package versions, review release notes before upgrades, and consider the single-maintainer risk in your adoption plan. Support follows the documented Support Policy.
🚀 Where to start
For a new provider, start with its package README and LIMITATIONS.md. Most are early releases, so validate them in your environment before production use.
If you are upgrading SQL Server, PostgreSQL, MySQL, or SQLite, review the breaking changes first. The type-conversion changes and required where arguments are the most likely to require code updates.
~ Conceptualized by me. Reviewed and checked by AI. Refined and gatekept by me. ~
Please support us
Give a ⭐ to our GitHub repository |
Follow me on X / Twitter |
Connect with us on our official Teams Channel
Apache License 2.0 — Copyright © 2026 by Michael Camara Pendon / Create a Request