Mapwright vs Mapperly vs AutoMapper

1. The short answer

If you are already on Mapperly and it is working, stay there — it is the mature source-generator mapper, and nothing on this page is worth a migration.

If you are on AutoMapper and want mappings the compiler checks, no runtime engine, and Native AOT that just works, then either generator is a real upgrade; pick Mapwright if you want generated code that reads like the code you would have written and a build that fails on stale configuration, and pick Mapperly if you want the larger community and the wider configuration surface. If your mappings are decided at runtime — assembled from configuration data, chosen by type discovered at execution time — stay on AutoMapper, because no compile-time generator can express that, Mapwright included.

2. Two models, three libraries

The important split is not three-way. It is two-way: when the mapping is resolved.

Everything below follows from that. Mapwright and Mapperly disagree about ergonomics and strictness; they agree completely against AutoMapper about when a mapping should be settled.

3. Feature matrix

The Mapwright column was verified against src/, tests/ and the README in this repository. The Mapperly column was verified against the abstractions assembly shipped in Riok.Mapperly 4.3.1 — the version benchmarks/Mapwright.Benchmarks references — and the AutoMapper column against AutoMapper 13.0.1 and its documented behavior. A dash means not verified here, not "missing": both libraries are large and both move faster than this page, so check their current docs before deciding on a dash.

✓ present  ·  ✗ not available  ·  — not verified

4. Where Mapperly wins

Mapperly is the mature choice, and if you are on it, the honest recommendation is to stay.

It is the incumbent source-generated mapper for .NET: a very large user base, years of production hardening across projects far stranger than yours, a real contributor community, and an edge-case catalogue that only time produces. Mapwright is new. When Mapwright meets a mapping shape nobody has tried yet, you will be the one who finds out; when Mapperly meets one, there is a good chance someone already filed the issue and it was fixed two releases ago. That difference does not show up in a feature table and it matters more than most rows in one.

The configuration surface is not close either, and it is measurable. Mapperly 4.3.1's [Mapper] attribute carries seventeen properties — reference handling, null-mismatch behavior, obsolete-member strategies, constructor selection, member visibility, enum naming strategies, enabled conversion sets — against four on Mapwright's. Its abstractions assembly publishes around thirty public types, including per-value enum mapping, object factories, mapper composition, named mappings and per-member format providers. Mapwright ships eight attributes. Where your mapping needs a knob, Mapperly is much more likely to have one.

Two concrete capabilities Mapwright does not have at all: reference handling (UseReferenceHandling, which preserves object identity across a cyclic graph — Mapwright turns cycles into recursive calls and does not track instances), and culture control (FormatProvider/StringFormat per member — Mapwright's scalar conversions are culture-invariant, full stop, which is the right default and not always the right answer).

And on the single-object benchmark in this repository, Mapperly is simply faster than Mapwright. The number is in section 7, unrounded.

5. Where AutoMapper wins

AutoMapper is a mature, very widely deployed library, and its ecosystem is in a different weight class: a decade of Stack Overflow answers, tutorials, conference talks, and colleagues who already know it. On an existing team, "everyone has used this before" is a genuine engineering property, not a soft one.

More importantly, its runtime model does something neither generator can. When the mapping itself is data — pairs discovered by scanning assemblies at start-up, member routing driven by a configuration file or a tenant record, a destination type chosen from a value that only exists at execution time — a compile-time generator has nothing to generate from. AutoMapper's configuration is built while the program runs, so it can. That is not a workaround for AutoMapper's model; it is the point of it, and if your application lives there, AutoMapper is the correct tool and Mapwright is not a candidate.

Its convention engine also does more guessing for you, which is a cost in a strict codebase and a saving in a fast-moving one. A prototype where a CreateMap<A, B>() covers forty properties without a word of configuration is a real convenience.

6. Where Mapwright wins

Five things, none of them "more features than the others":

• The generated code is meant to be read. Object initializers, a visible GetValueOrDefault() where a nullable column collapses, a null-guard before a nested map. Turn on <EmitCompilerGeneratedFiles> and it lands in obj/generated as the samples in this repository do; git diff shows behavior changes, and breakpoints work. There is no engine to reverse-engineer.
• Configuration cannot rot. An unmapped destination property is MW0001 on every keystroke, and — the part that matters — a [MapIgnore] or [MapProperty] naming a member that no longer exists is MW0003, a build error. Ignore lists that quietly stop matching anything are one of the standard failure modes of mapping configuration, and here they are not possible.
• The strongest collection path in the benchmark, by a margin that comes from a specific implementation choice rather than luck: the element loop writes straight into a pre-sized List backing span. Section 7 has the numbers.
• MIT, and nothing executes at run time. The attributes package multi-targets netstandard2.0, net8.0 and net10.0; the generator is a build-time analyzer that ships no lib/ and adds no runtime dependency. Native AOT and trimming are not a compatibility exercise.
• It updates an existing object graph in place. With [Mapper(ExistingTargets = ExistingTargetStrategy.Merge)] an in-place copy onto an EF Core tracked aggregate copies into the nested instances the target already holds and merges child collections by key — matched elements updated, new ones added, missing ones removed — instead of replacing them, which is what turns an update into a delete-and-insert of every child row. Mapperly replaces nested targets (its issue #1311, open since 2024) and has no collection merge (#665, open since 2023); AutoMapper needs the separate AutoMapper.Collection package. A collection with no recognizable key is a build error, not a silent replace.

7. Performance, read honestly

benchmarks/Mapwright.Benchmarks maps an order with a nested customer and ten lines, four ways (BenchmarkDotNet, .NET 10, Intel i5-1035G1). The table below is reproduced verbatim from the repository README — absolute nanoseconds are machine-specific, so read the ratios and the allocations:

The honest reading, in order:

• Mapperly is faster on a single object — 96.6 ns against Mapwright's 105.3 ns, about an 8% edge, from less call indirection in a small domain. Allocations tie exactly at 696 B. This is a real result and it is not going to be argued away.
• Mapwright leads the collection benchmark — 10.8 µs against Mapperly's 12.0 µs and hand-written LINQ's 13.2 µs, with allocations again tied to Mapperly at 70,456 B. The element loop writes into a pre-sized List backing span (CollectionsMarshal.SetCount + AsSpan): no enumerator, no per-element delegate, no Add capacity checks. That path needs CollectionsMarshal.SetCount, so it is what .NET 8 and later get; older targets get the same loop pre-sized with Add — same result, same allocations, one extra bounds check per element.
• AutoMapper costs 1.75–2.07× across both cases and allocates more, which is the price of resolving the mapping at run time.

dotnet run -c Release in benchmarks/ reproduces the table on your own hardware, which is the only version of it that should convince you.

8. Migration effort

From AutoMapper

This is the substantial one, because the model changes. Each CreateMap<A, B>() becomes one static partial method on a [Mapper] class; each ForMember(..., opt => opt.Ignore()) becomes a [MapIgnore(nameof(...))]; ProjectTo<T>() becomes an Expression<Func<,>> or IQueryable<T> partial; IncludeAllDerived() becomes explicit [MapDerivedType] pairs; value resolvers that need services become hand-written methods on an instance mapper. The injected IMapper disappears, and with it the DI registration.

The work is front-loaded and noisy in a good way: the generator reports every destination member your profiles were silently leaving unset, so the migration usually surfaces bugs that were already in production. Budget it per profile, not per property. The case study walks an eight-entity profile through end to end.

From Mapperly

Mechanically much smaller — both are declare-a-partial-method generators, and the shapes line up closely — but the honest advice is don't. You would be trading a mature library for a new one to gain readable output, build-failing configuration rot and a faster collection path, while giving up reference handling, format providers, the wider configuration surface and the community. That is a bad trade for a working system. Mapwright is worth evaluating on a new project, or when one of its specific properties is something you actually need.

9. When not to use Mapwright

A comparison that recommends its own library everywhere is not worth reading. These are the cases where the answer is another tool:

10. Licensing, factually

Stated plainly and without spin, because licensing is a decision input and not an argument: Mapwright is MIT and free for commercial use, with no runtime component to license. Mapperly 4.3.1 ships under Apache-2.0 per its package metadata. AutoMapper's terms changed in 2025 — package 13.0.1 declares the MIT expression, while 16.0.0 ships a license file offering RPL-1.5 or a separate commercial agreement.