When Your Safe Default Becomes a Liability: AutoMapper and the Real Cost of Open Source Decisions

I've been using AutoMapper since 2015. It's been in every enterprise project I've worked on—three companies, countless codebases. The kind of tool that becomes so embedded in your workflow you forget you're even using it. Then one Tuesday last month, someone in our Slack shared a news post about AutoMapper going commercial. My first reaction was dismissive: "Ok, still free for us, move on." Then I read about CVE-2026-32933.

A denial-of-service vulnerability with no free patch available. That's the moment the comfortable relationship ended. Suddenly AutoMapper wasn't a solved problem anymore—it was a decision that needed immediate revisiting. And that meant I had to actually figure out what to replace it with. The problem? Nobody had current data.

The Problem With Stale Benchmarks

When you're trying to evaluate alternatives to a tool you've relied on for years, you want numbers. Hard data. What I found instead were blog posts from 2021, some with .NET Core 3.1 benchmarks, and GitHub discussions where people were arguing about Mapster vs. AutoMapper based on anecdotal performance claims from 2019.

The real issue isn't that old benchmarks are wrong—it's that they're deceptively useful. They feel authoritative because someone put effort into them. But libraries evolve. .NET runtime improvements change optimization patterns. What was slow three years ago might be fast now. A benchmark from 2021 isn't just old; it's actively misleading because it carries false precision.

I needed to understand how these tools actually perform in 2025. On my current stack. With current versions.

Why Building Living Benchmarks Matters

What Jagoba did here is clever. Instead of taking a snapshot and publishing it, they built an automated system that runs benchmarks continuously on a VPS. The library versions auto-update. Results get averaged over three months to eliminate lucky runs. The benchmarks stay alive.

This is the right approach, and I wish more library comparisons worked this way. It acknowledges a fundamental truth: performance characteristics are temporal. They change. Any meaningful benchmark has an expiration date, and most benchmark posts don't acknowledge theirs.

The scenarios measured are practical too—flat objects, nested graphs, collections, property name mismatches. These aren't synthetic edge cases. These are the four patterns you actually write code for.

What This Means for My Projects

For me, this raises a bigger question than just "which mapper should I use?" It's about how I evaluate dependencies when the vendor relationship changes.

AutoMapper's commercialization isn't inherently bad. Open source maintainers deserve compensation. But the structure—free tier freezes at a vulnerable version while paid tiers get fixes—creates a real security maintenance problem for companies that hit the revenue threshold. That's not a theoretical concern for us; we're close to the $5M line. Suddenly there's clock ticking on an obligation to migrate.

What I would do: I'd open the live benchmark data, filter for "realistic production workload" scenarios (nested objects, collections), and run my own fork of the benchmark against my actual use cases. Generic benchmarks help, but they're still generic. A benchmark of mapping a User to UserDTO doesn't tell you how your 5-level-deep domain model mapping will perform.

Then I'd prototype the migration with the top two candidates in a branch. Actual code reveals friction that benchmarks don't—integration with DI containers, how fluent the configuration API feels, whether it plays nicely with your existing patterns.

A Practical Consideration

If you're migrating, the cost isn't just benchmarking. It's the refactoring. AutoMapper profiles are different from Mapperly's approach (which uses source generators) or Mapster's fluent configuration. You're rewriting configuration across dozens of files, potentially.

That's worth factoring into your decision alongside the raw nanoseconds-per-operation numbers.

What's Your Baseline?

If you're in a similar spot—facing an AutoMapper migration or any major dependency replacement—what's your approach? Do you benchmark first and decide, or do you just pick the most popular alternative and spend a week refactoring?

I'm leaning toward the live benchmark data plus a quick prototype sprint. But I'm curious if that's overengineering something that should just be a "Mapperly is faster, let's go" decision.

Source: This post was inspired by "I needed up-to-date .NET mapper benchmarks. They didn't exist." by Dev.to. Read the original article