// the find
borisdj/EFCore.BulkExtensions
Entity Framework EF Core efcore Bulk Batch Extensions with BulkCopy in .Net for Insert Update Delete Read (CRUD), Truncate and SaveChanges operations on SQL Server, PostgreSQL, MySQL, SQLite, Oracle
EFCore.BulkExtensions adds high-performance bulk CRUD operations to EF Core, bypassing the ORM's row-at-a-time change tracker in favor of database-native bulk copy protocols. It supports all five major SQL databases and is well-suited for data import pipelines, sync jobs, or any .NET app that needs to move tens of thousands of rows at once. Not a niche tool — Microsoft listed it in their official EF Core extensions page.
Each provider uses the right native mechanism: SqlBulkCopy for SQL Server, COPY BINARY for PostgreSQL, MySqlBulkCopy for MySQL — not a lowest-common-denominator fallback. The BulkConfig surface is genuinely thorough: PropertiesToIncludeOnUpdate, OnConflictUpdateWhereSql, SetSynchronizeFilter, DoNotUpdateIfTimeStampChanged — real production scenarios are covered without hacks. Per-provider NuGet packages mean you don't drag in MySQL drivers if you only use PostgreSQL. BulkSaveChanges integrates with the EF change tracker so existing code can adopt it incrementally rather than rewriting every data access path.
The dual license (cFOSS) is a real adoption risk for commercial teams — the line between 'community' and 'commercial' use is defined on an external website, not in the repo, which means your legal team gets to have fun. PostgreSQL BulkInsertOrUpdateOrDelete (full sync) is not supported — you have to manually split into BulkInsertOrUpdate + BulkDelete, which defeats the point for users on Postgres. WithHoldlock defaults to true, which takes a serializable table lock; the README buries this in a config footnote rather than making it a first-class warning, and it will cause surprise deadlocks under concurrent write workloads. MySQL support is stuck on EF Core 9 because the provider hasn't shipped an EF 10 update yet, so EF 10 shops on MySQL are blocked.