DEV Community: Daniel Davis

Your users upload 12MP phone photos. Your app shouldn't serve them raw.

Daniel Davis — Mon, 09 Nov 2026 22:48:03 +0000

If you have ever wired up an ASP.NET Core photo upload and watched a 12-megapixel phone JPEG land in blob storage at full size, sideways, with GPS still in the EXIF, you already know the feeling. The endpoint works. The CDN bill and the broken avatars arrive later.

I also know the other path by heart: pull in SkiaSharp, remember which native asset package Linux needs, apply EXIF orientation yourself, pick a fit mode that does not letterbox by accident, binary-search JPEG quality until the file is under 100 KB, and hope nobody posts a decompression bomb. It works. It is also easy to get slightly wrong on the second feature.

So I built PicReady: a small .NET 8/9 library that wraps SkiaSharp for the everyday web-app jobs — resize, crop, avatar, WebP, strip EXIF, hit a max byte size — behind a short fluent API. PicReady.Lite is the free MIT subset for a plain resize. This post is the problem, the API, real numbers from one stopwatch run, and when you should not use it.

Why raw uploads hurt

Phone cameras send large JPEGs. Many are tagged with Orientation 6 or 8, so the pixels are sideways until something rotates them. If you store the file as-is, every viewer has to guess. If you resize without applying that tag first, the crop is wrong and the avatar looks like it fell over.

There is also the safety problem. A tiny PNG whose header claims a huge canvas can chew through memory before your code ever draws a pixel. On a public upload endpoint that is not a theoretical concern.

Why hand-rolled SkiaSharp is fiddly

SkiaSharp is excellent and MIT licensed. It is also a drawing toolkit, not an upload pipeline. Fit modes, EXIF orient-then-strip, "encode until under N bytes," circle avatars, responsive size sets, and an IFormFile helper are all things you end up writing yourself. Magick.NET covers more ground, but it brings native ImageMagick dependencies. System.Drawing is the wrong tool for modern ASP.NET Core on Linux.

ImageSharp covers general imaging well. For closed-source, for-profit teams over the community threshold, Six Labors lists Boutique at $799/year for up to 10 developers, with a build-time license key on current versions. That is a fair price for a full imaging suite. It is a lot if all you needed was "turn this upload into a 1280px WebP under 180 KB."

What PicReady does

PicReady wraps that upload → ready-to-serve path:

using PicReady;

PicReadyLicense.Register(licenseKey);

var webp = PicJob.Load(upload)
    .Resize(960, 960, FitMode.Cover)
    .Webp(80)
    .ToBytes();

Under the hood it still uses SkiaSharp. It applies EXIF orientation and strips metadata by default, supports Contain / Cover / Stretch / MaxWidth / MaxHeight, circle and rounded-rect avatars, text and image watermarks, ResizeMany for responsive sets, MaxBytes quality search, batch processing with a parallelism bound, and ASP.NET Core IFormFile helpers. Hard safety caps reject oversized headers before Skia allocates a decoded bitmap.

Install Pro:

dotnet add package PicReady

If you only need a plain JPEG/PNG resize, the free MIT sibling PicReady.Lite has the same Contain/Cover fit API and no license key:

dotnet add package PicReady.Lite

using PicReady;

var thumb = LiteJob.Load(upload)
    .Resize(480, 480, FitMode.Contain)
    .Background(RgbColor.White)
    .Jpeg(JpegPreset.Medium)
    .ToBytes();

Both packages target .NET 8 and .NET 9. There is no System.Drawing and no ImageSharp dependency. Native Linux assets come from SkiaSharp.NativeAssets.Linux.NoDependencies, so a normal dotnet restore on Docker/Linux does not need a system libfontconfig.

A few friendly examples

Avatar upload, WebP under 100 KB. Cover-fit into a square, clear the corners, then binary-search quality until the file fits the budget:

var avatar = PicJob.Load(upload)
    .Circle(256)
    .MaxBytes(100 * 1024, OutputFormat.Webp)
    .ToBytes();

PNG and WebP keep the outside of the circle transparent. JPEG paints AvatarBackground (transparent becomes white). If even the lowest allowed quality is still too big, MaxBytes throws and names the budget and the smallest size it reached.

Product images at 320, 640, and 1280. One decode, then one encode per longest side, in the order you asked for:

var set = PicJob.Load(upload)
    .Png()
    .ResizeMany(320, 640, 1280);

Strip camera EXIF. Orientation is applied by default, then metadata is dropped, so a phone photo is stored upright and a later viewer does not rotate it again:

var stored = Pic.Process(upload, new PicSettings
{
    Width = 1600,
    Fit = FitMode.MaxWidth,
    Format = OutputFormat.Jpeg,
    Quality = 85
});

var info = Pic.GetInfo(stored);
// info.HasExif is false. info.ExifOrientation is 1.

ASP.NET Core IFormFile. The content type comes from the bytes you asked to encode, not from the filename:

using PicReady.AspNetCore;

app.MapPost("/photos", async (IFormFile file) =>
{
    var settings = new PicSettings
    {
        Width = 1280,
        Fit = FitMode.MaxWidth,
        Format = OutputFormat.Webp,
        MaxBytes = 180 * 1024
    };
    var bytes = await PicFormFile.ProcessAsync(file, settings);
    return Results.File(bytes, PicContent.GetContentType(settings.Format));
});

An empty upload throws. PicContent.TryDetect sniffs JPEG, PNG, GIF, and WebP headers.

Batch a folder. A bad file is reported on that index; the rest of the batch continues:

var files = Directory.GetFiles(inbox, "*.jpg");
var results = await Pic.BatchProcessAsync(
    files,
    path => Path.Combine(outbox, Path.GetFileNameWithoutExtension(path) + ".webp"),
    new PicSettings { Width = 1600, Fit = FitMode.MaxWidth, Format = OutputFormat.Webp, Quality = 80 },
    maxDegreeOfParallelism: 4);

foreach (var item in results.Where(item => !item.Success))
    Console.Error.WriteLine($"{item.SourcePath}: {item.Error}");

Contain, Cover, and Stretch

Mode	Result
`Contain`	The whole image is inside the box. The leftover area is `Background`. Nothing is cropped.
`Cover`	The box is filled. Overflow is cropped using `Gravity` or a focal point. No letterbox.
`Stretch`	Exact box. Aspect ratio is not kept.
`MaxWidth` / `MaxHeight`	One side is fixed; the other follows the aspect ratio.

Protection against decompression bombs

Before Skia allocates a decoded bitmap, PicReady checks the header against hard caps: longest side 16384, 80 million pixels, 200 MB input. Defaults are lower (8192, 40 million pixels, 80 MB). Raising a setting never goes past the hard cap. A header over the cap throws a managed PicException instead of letting the process balloon.

Numbers from one stopwatch run

These are from a Release stopwatch harness (one warmup, five iterations, median) on our benchmark machine: 4 processors, source 1280×720 noise, output 640×360 Contain. This is not a BenchmarkDotNet suite and not a laptop claim. Your hardware will differ.

Pipeline	.NET 8.0.33	.NET 9.0.22
Decode, resize, JPEG quality 80	46.4 ms	48.0 ms
Decode, resize, WebP quality 80	74.3 ms	76.8 ms
Same JPEG with `MaxBytes` 80 KB	135.7 ms	134.3 ms

MaxBytes encodes several qualities on purpose, so it is slower than a single encode.

When you should not use this

If you need a full pixel API, custom shaders, or ImageSharp's general imaging surface, PicReady is the wrong tool. It is built for upload → oriented, fitted, encoded file.

If you only need a plain resize to JPEG or PNG and you want zero licensing, start with Lite instead of Pro.

If you need HEIC, AVIF, TIFF, animated GIF encode, lossless WebP, or CMYK output, this package will not help you. GIF and animated WebP decode the first frame only. CMYK JPEG is decoded to RGB.

If you are already happy with Magick.NET's native stack or with ImageSharp's suite and its commercial terms, keep them. PicReady is meant for the teams that wanted a smaller, cheaper upload helper — not a drop-in ImageSharp replacement.

Try it without buying anything

PicReady.Lite is MIT licensed: load from path / stream / bytes, fit modes, JPEG and PNG only, fixed quality presets.

dotnet add package PicReady.Lite

PicReady adds WebP, EXIF orient+strip, MaxBytes, crop/focal, avatars, watermarks, ResizeMany, batch, async parity, and IFormFile helpers. You can try it without a key: every output is still a valid JPEG/PNG/WebP of the same dimensions, with a small corner "PicReady trial" mark. Outside Development, a 14-day window starts on first use; Development does not expire that window.

dotnet add package PicReady

When you have a key, register it at startup or set an environment variable. A missing variable leaves the library in trial mode. It does not throw.

using PicReady;

PicReadyLicense.Register(builder.Configuration["PicReady:LicenseKey"]!);

export PICREADY_LICENSE_KEY="paste-the-key-here"

You can also drop the token in a picready.lic file next to the app, or in license.key under the PicReady app-data folder. The key is checked offline; the package does not phone home. An invalid key fails closed with a clear message; a valid key already active stays in place.

	PicReady.Lite	PicReady
License	MIT	Commercial EULA, offline key
Decode	JPEG, PNG, GIF (first frame)	Same, plus WebP
Encode	JPEG, PNG	JPEG, PNG, WebP
Fit modes	Contain, Cover, Stretch, MaxWidth, MaxHeight	Same
EXIF orient and strip	No	Yes
Crop, avatar, watermark, `MaxBytes`, batch, `IFormFile`	No	Yes

If Pro fits, licenses are $19 per developer per year (1–50 seats) or $79 per year for a team of up to 10 developers. The key is emailed within about an hour of checkout. Questions and feedback are welcome at dbdavis1990apple@gmail.com.

I built this because I was tired of choosing between a raw SkiaSharp paste and a commercial imaging suite priced for a much bigger job. If it turns one phone upload into a file you can actually serve, it did what I hoped.

SaveChanges shouldn't take four seconds to insert 100,000 rows

Daniel Davis — Mon, 09 Nov 2026 20:51:16 +0000

If you have ever watched an import job stall after AddRange and SaveChanges, you already know the feeling. EF Core is doing honest work: it tracks every entity, generates commands, and talks to SQL Server more than you wanted. That is the right tradeoff when you are saving a cart or a user profile. It is a painful one when you are writing thousands or hundreds of thousands of rows.

I also know the other path by heart: SqlBulkCopy into a temp table, a MERGE with HOLDLOCK so two imports do not race, a transaction you actually commit, and a decision about identity values. It works. It is also easy to get slightly wrong.

So I built SqlBulkPro: a small .NET 8/9 library that uses SqlBulkCopy and MERGE under the hood and gives you one method for the usual cases. It works with EF Core and with Dapper / ADO.NET. This post is the problem, the API, real numbers from one benchmark machine, and when you should not use it.

Why `SaveChanges` slows down at volume

EF Core is a change tracker first and a SQL generator second. For a handful of rows that is a gift. At a few thousand rows, every entity is tracked, and setup plus round-trip overhead starts to dominate. That is not a knock on EF Core. I still use it for the rest of the app. I just stopped asking it to be a bulk loader.

There is another long-open gap: EF Core has no built-in upsert. If you have followed dotnet/efcore#4526 since 2016, you have probably written the same "try update, else insert" loop more than once.

Why hand-rolled `SqlBulkCopy` + `MERGE` is fiddly

SqlBulkCopy is fast because it is a streaming bulk path into SQL Server. Insert-only is the easy part. The moment you need "insert if new, update if the key already exists," you are creating a temp table, bulk-copying into it, MERGEing with HOLDLOCK if two writers can collide, and keeping the whole thing in one transaction so a failed merge does not leave a half-written table.

It is easy to skip the lock hint or forget to enlist SqlBulkCopy in the transaction. Those bugs are rare until they are not.

What SqlBulkPro does

SqlBulkPro wraps that pattern behind a boring API:

using SqlBulkPro;

await dbContext.BulkInsertAsync(products);
await dbContext.BulkUpsertAsync(products);
await dbContext.BulkUpdateAsync(products);
await dbContext.BulkDeleteAsync(products);

Under the hood it still uses SqlBulkCopy and MERGE. It supports composite keys, identity values written back onto your entities, EF Core value converters, HOLDLOCK when you want to prevent races, batch size and timeout settings, column include/exclude lists, and ambient transactions. The hot path uses compiled expressions, not per-row reflection.

Install:

dotnet add package SqlBulkPro

If you only need insert, the free MIT sibling SqlBulkPro.Lite has the same insert API and no license key.

It targets .NET 8 and .NET 9, talks to SQL Server 2016 or later, and the EF helpers expect EF Core 8 or later.

A few friendly examples

EF Core insert. This is the one-liner for an import job that would otherwise call AddRange + SaveChanges:

using SqlBulkPro;

var products = LoadProductsFromFile(); // thousands of rows
await dbContext.BulkInsertAsync(products);

Upsert with your own key columns. Useful when the natural key is not the identity column — a product code plus a region, a source system id, and so on:

using SqlBulkPro;

var options = new BulkOptions
{
    KeyColumns = new List<string> { "ProductCode", "Region" },
    ColumnsToIgnore = new List<string> { "LastModified" },
    InsertOnlyColumns = new List<string> { "CreatedAt" },
    BatchSize = 10000,
    TimeoutSeconds = 60,
    UseHoldLock = true,
    ReturnIdentities = true
};

await dbContext.BulkUpsertAsync(products, options);

KeyColumns tells MERGE how to match. ColumnsToIgnore stays out of the update. InsertOnlyColumns is written on insert and left alone later (CreatedAt is the usual case). UseHoldLock prevents concurrent upserts from racing. ReturnIdentities writes generated ids back onto the objects you passed in.

Dapper / ADO.NET. If you are not using a DbContext for the write path, the same operations hang off SqlConnection. You can point at a table and name the key with a short fluent config:

using SqlBulkPro;
using Microsoft.Data.SqlClient;

using var connection = new SqlConnection(connectionString);

await connection.BulkInsertAsync(products);

await connection.BulkUpsertAsync(products, config => config
    .ToTable("Products", "dbo")
    .HasKey(nameof(Product.Id)));

Inside a transaction. The library respects ambient transactions, so a bulk write can sit next to other work and commit or roll back together:

using SqlBulkPro;
using System.Transactions;

using var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled);

await dbContext.BulkInsertAsync(newProducts);
await dbContext.BulkUpsertAsync(existingProducts, options);

scope.Complete();

That way a bulk write can succeed or fail together with the rest of the unit of work.

Numbers from our benchmark machine

These are from one BenchmarkDotNet run (1 warmup, 3 measured iterations) on our benchmark machine: a 4-core Xeon, .NET 9, and SQL Server 2022 in Docker on that same box. Insert compares AddRange + SaveChanges with BulkInsertAsync. "Update vs upsert" compares UpdateRange + SaveChanges with BulkUpsertAsync after the rows already exist. Your hardware and indexes will differ; this is what that machine measured.

Operation	Rows	EF Core mean	SqlBulkPro mean	EF / SqlBulkPro
Insert	1,000	96.96 ms	17.84 ms	5.4×
Insert	10,000	517.66 ms	54.06 ms	9.6×
Insert	100,000	3,768.89 ms	554.19 ms	6.8×
Update vs upsert	1,000	106.31 ms	28.11 ms	3.8×
Update vs upsert	10,000	614.58 ms	109.36 ms	5.6×
Update vs upsert	100,000	5,226.42 ms	856.17 ms	6.1×

On that run, 100,000 inserts went from about 3.8 seconds to about 0.55 seconds. Across these cases the mean time was roughly 4× to 10× lower than SaveChanges.

When you should not use this

If you are saving 10 or 50 rows, stay with SaveChanges. The bulk path has setup cost, and EF Core's usual pipeline is simpler, more visible in logs, and plenty fast at that size.

If you need a graph of parents, children, and owned types saved with the full change tracker, this is the wrong tool. SqlBulkPro is for flat sets of rows headed at a table.

If you only need insert and you want zero licensing, start with Lite instead of Pro. And if your database is not SQL Server 2016 or later, this package will not help you. It is built around SqlBulkCopy and MERGE.

Try it without buying anything

SqlBulkPro.Lite is MIT licensed and insert-only:

dotnet add package SqlBulkPro.Lite

SqlBulkPro adds upsert, update, delete, and sync. You can try it without a key: each operation is capped at 1,000 rows, and a 14-day trial check runs outside Development. In Development (or with a debugger attached) that 14-day check is skipped; the row cap still applies.

dotnet add package SqlBulkPro

When you have a key, register it at startup or set an environment variable. A missing variable leaves the library in trial mode. It does not throw.

using SqlBulkPro;

var builder = WebApplication.CreateBuilder(args);
SqlBulkProLicense.Register(builder.Configuration["SqlBulkPro:LicenseKey"]!);

export SQLBULKPRO_LICENSE_KEY="paste-the-key-here"

If Pro fits, licenses are $149 per developer per year or $599 per year for a team of up to 10 developers. The key is emailed after checkout. Questions and feedback are welcome at dbdavis1990apple@gmail.com.

I built this because I was tired of choosing between a slow SaveChanges and a MERGE script I did not want to maintain again. If it saves you that choice on one import job, it did what I hoped.

DEV Community: Daniel Davis

Your users upload 12MP phone photos. Your app shouldn't serve them raw.

Why raw uploads hurt

Why hand-rolled SkiaSharp is fiddly

What PicReady does

A few friendly examples

Protection against decompression bombs

Numbers from one stopwatch run

When you should not use this

Try it without buying anything

SaveChanges shouldn't take four seconds to insert 100,000 rows

Why SaveChanges slows down at volume

Why hand-rolled SqlBulkCopy + MERGE is fiddly

What SqlBulkPro does

A few friendly examples

Numbers from our benchmark machine

When you should not use this

Try it without buying anything

Why `SaveChanges` slows down at volume

Why hand-rolled `SqlBulkCopy` + `MERGE` is fiddly