The day AutoMapper stopped being a no-brainer

For years, AutoMapper was the default. You added the NuGet package, wrote a profile, and never thought about it again. That changed for me in 2025.

Two things happened almost back to back:

1. AutoMapper went commercial. On July 2, 2025, Jimmy Bogard announced commercial editions of AutoMapper (and MediatR) under a new company, Lucky Penny Software. It's still free for individuals and companies under $5M USD in annual revenue, but above that you now need a paid license. (announcement)
2. The last freely-patchable version got a high-severity CVE. CVE-2026-32933 (CVSS 7.5, High) is a Denial-of-Service via uncontrolled recursion: map a deeply nested object graph and you get a StackOverflowException that takes the whole process down, and in modern .NET you can't even catch it. The catch? The fix landed in the paid versions (15.1.1 / 16.1.1).

So if you're on the free track, you're sitting on a known DoS with no free upgrade path. At work, that meant one thing: we had to migrate AutoMapper out of every project.

The problem: nobody had fresh numbers

There's no shortage of candidates: Mapperly, Mapster, TinyMapper, AgileMapper, or just writing the mapping by hand. The hard part wasn't finding options, it was figuring out which one to actually trust in production, and that's a call you want to make with data, not vibes.

I went looking for benchmarks and hit a wall:

• Most comparisons were years old.
• None were run against .NET 10.
• Library versions were stale, so the conclusions no longer applied.
• Everyone benchmarked slightly different scenarios, so you couldn't compare apples to apples.

Performance characteristics change with every runtime and every library release. A benchmark from 2021 tells you almost nothing about Mapperly 4 on .NET 10. I didn't want a snapshot. I wanted something that stays true over time.

So I built it.

The solution: benchmarks that never go stale

I built a BenchmarkDotNet runner that measures the major .NET mappers across consistent scenarios, plus a small landing page to read the results.

What makes it different from the "I benchmarked these one afternoon in 2022" posts:

• It runs every hour on a dedicated VPS, automatically.
• Library versions auto-update to the latest release, so the numbers always reflect what you'd actually install today.
• Results are averaged over the last 3 months to smooth out noise and show long-term trends, not a single lucky run.
• No raw JSON, no markdown walls, just clean, interactive charts.

What I measure

Four scenarios that cover the cases you hit in real code:

For each one: mean execution time (μs) and memory allocated per operation (bytes).

Why I'm not posting the numbers here

This is the part where a normal post drops a table of results and tells you which library "wins."

I'm not going to do that, on purpose.

If I freeze the numbers into this article, it becomes exactly the thing that sent me down this road in the first place: an outdated benchmark. In six months the versions will have moved, .NET will have a new release, and a screenshot from today would be quietly lying to whoever finds this post later.

So instead of conclusions, here's the live data, always current:

benchmarks.jagoba.dev/dotnet-mappers

Open it, pick the scenario that matches your workload, and read today's results instead of mine from whenever you happen to read this.

Try it / steal it

• Live benchmarks: benchmarks.jagoba.dev/dotnet-mappers
• Benchmark runner: github.com/jagobainda/DotnetMappingBenchmarks
• The website: github.com/jagobainda/dotnet-mapping-benchmarks-web

If AutoMapper's licensing change or the CVE has you reconsidering your mapping layer, I hope this saves you the afternoon of benchmarking I had to do. And if you spot a scenario worth adding, the runner is open source, PRs welcome.

What did you migrate to? I'm curious whether others landed on Mapperly, Mapster, or just went manual.

---

Sources: AutoMapper commercial editions announcement · GHSA-rvv3-g6hj-g44x / CVE-2026-32933