MediatR vs Wolverine vs Brighter in .NET: Which Mediator Should Your Team Use in 2026?

MediatR, Wolverine, and Brighter are the three leading mediator and in-process messaging libraries for .NET teams. With MediatR moving toward a commercial licensing model in its upcoming versions, teams are actively evaluating their options for 2026. Choosing the wrong one locks you into assumptions that are expensive to undo once your codebase scales. This article gives you the side-by-side comparison you need to make a confident architectural decision.

🎁 Want implementation-ready .NET source code you can drop straight into your project? Join Coding Droplets on Patreon for exclusive tutorials, premium code samples, and early access to new content. 👉 https://www.patreon.com/CodingDroplets

What Problem Are These Libraries Solving?

All three libraries address the same core challenge: decoupling the sender of a request from its handler. Rather than calling services or repositories directly, you dispatch a command or query through a mediator interface. The mediator resolves the correct handler, runs any cross-cutting pipeline behaviors, and returns the result. This pattern maps naturally onto CQRS and keeps controllers and API endpoints thin.

The similarities end there. MediatR is a focused in-process mediator. Wolverine is a full messaging platform — it handles both in-process dispatch and distributed messaging across message brokers. Brighter is a mature enterprise framework designed for both local and distributed workflows with a strong emphasis on observability and resilience built into the library itself.

MediatR: The Default Choice and Its Limits

MediatR by Jimmy Bogard became the de facto standard for in-process CQRS in the .NET ecosystem. It is simple, well-documented, and widely adopted. The interface is familiar: you define a request, implement IRequestHandler<TRequest, TResponse>, and call mediator.Send(request). Pipeline behaviors give you a clean way to add cross-cutting concerns like logging, validation, and caching without coupling them to your handlers.

The limitations are equally well-documented in the community. MediatR is purely in-process. If you need to publish a message to a queue or handle background processing, you must bolt on a separate tool. The library uses reflection for handler discovery, which adds startup cost in large applications. Performance benchmarks consistently show higher latency compared to source-generated alternatives. And as of 2026, the commercial licensing direction signals that enterprise teams should treat free usage as a risk to manage.

When MediatR is still the right choice:

• Your team is already standardized on it and has no scaling pressure
• In-process dispatch is the only requirement — no distributed messaging needed
• You prioritize stability and ecosystem familiarity over performance
• Your team's size or budget makes the licensing discussion straightforward

When to move on from MediatR:

• You need in-process and distributed messaging from a single abstraction
• Performance benchmarks matter (high-throughput API or real-time workloads)
• You want a zero-dependency solution that doesn't require a commercial license for production use

Wolverine: The Full-Stack Mediator and Message Bus

Wolverine (part of the Critter Stack, built by Jeremy Miller) is positioned as a "next-generation" mediator — but calling it just a mediator undersells it. Wolverine handles in-process dispatch, distributed messaging via RabbitMQ or Azure Service Bus, durable outbox patterns, saga orchestration, and scheduled job execution. All of these use the same handler convention.

The key design decision in Wolverine is convention-over-configuration. You do not implement an interface. You write a class with a Handle(MyCommand command) method and Wolverine discovers and compiles it at startup using source generators. This gives you significantly lower dispatch overhead than reflection-based frameworks. The compiled pipeline is type-safe and performs close to direct method call latency in benchmarks.

Wolverine integrates tightly with Marten (the .NET document/event store on PostgreSQL), which makes it a natural fit for teams pursuing event sourcing or event-driven architectures without pulling in multiple separate tools.

Side-by-side feature comparison: MediatR vs Wolverine vs Brighter

Feature	MediatR	Wolverine	Brighter
In-process dispatch	✅	✅	✅
Distributed messaging	❌	✅	✅
Handler convention	Interface	Convention (source gen)	Base class
Pipeline behaviors	✅	✅ (middleware)	✅ (request handlers)
Outbox pattern	❌ (manual)	✅ (built-in)	✅ (built-in)
Sagas / state machines	❌	✅	✅
Background job scheduling	❌	✅	❌ (external)
Source generator dispatch	❌	✅	❌
OpenTelemetry integration	3rd party	Built-in	Built-in
License	Commercial (v13+)	MIT	MIT
Learning curve	Low	Medium	Medium-High

When Wolverine is the right choice:

• Your team wants a single framework for in-process and distributed messaging
• You are building event-driven architectures and may use Marten or PostgreSQL as a backing store
• Performance and low dispatch latency are non-negotiable
• You want the outbox pattern and saga support without adopting a separate framework

When to avoid Wolverine:

• Your team is deeply invested in the IHandler<T> interface pattern and conventions are a culture mismatch
• You are on a pure Azure-native stack where NServiceBus has deeper platform integrations
• The Critter Stack dependency chain is more than your governance allows

Brighter: Enterprise-Grade Reliability and Portability

Brighter (maintained by the Paramore project) takes a more formal enterprise approach. Like Wolverine, it supports both in-process and distributed messaging. Unlike Wolverine, it does not use convention-based discovery — your commands inherit from a Command base class and your handlers implement a typed interface. This explicitness is a deliberate design choice that prioritizes clarity over magic.

Brighter's differentiating strengths are its built-in support for the Request-Reply, Command Dispatcher, and Event Driven Consumer enterprise integration patterns, a well-tested port to multiple message brokers (RabbitMQ, SNS/SQS, Azure Service Bus, Kafka), and a dedicated emphasis on production resilience. Brighter ships with circuit breaker, retry, and timeout policies as first-class concepts rather than delegating them to Polly configuration.

The observability story in Brighter is also a strong enterprise selling point. OpenTelemetry instrumentation is built into the dispatch pipeline, and the framework emits spans and metrics that map to standard semantic conventions. Teams running Datadog, Grafana, or Azure Monitor get useful signal out of the box.

When Brighter is the right choice:

• Your team values explicit, interface-driven patterns over conventions
• You need multi-broker portability across RabbitMQ, SQS/SNS, Azure Service Bus, or Kafka
• Built-in resilience policies (retry, circuit breaker) at the framework level are a requirement
• Enterprise integration pattern literacy is high on your team and you want a framework that speaks that language

When to avoid Brighter:

• Developer onboarding time is a priority — Brighter has the steepest initial learning curve of the three
• You want background job scheduling included without adding a separate tool
• Your use case is purely in-process with no distributed messaging requirements

Which Should Your Team Use in 2026?

The honest answer depends on where you are in your architecture journey.

Stick with MediatR if your codebase is already standardized on it, the in-process-only constraint fits your system, and the commercial licensing discussion resolves cleanly for your team. Switching frameworks has a real cost, and there is no mandatory reason to move unless your requirements have changed.

Choose Wolverine if you are building or refactoring toward an event-driven or distributed system and want a single consistent abstraction for both in-process and cross-process messaging. The performance advantage and the built-in outbox and saga support make it the strongest architectural foundation of the three for teams that expect their system to grow.

Choose Brighter if you are in an enterprise environment with strict governance requirements, need broker portability across multiple cloud vendors, and value the explicit, pattern-driven design over convention-based discovery. Brighter's resilience-first approach also makes it compelling for regulated industries where availability and audit are non-negotiable.

Do not mix all three in the same application. Pick one and standardize. The mediator pattern's value comes from consistency — having three different handler conventions in the same service undermines the abstraction entirely.

What Does Migration Look Like?

If you are moving from MediatR to Wolverine, the concept map is direct: IRequest<T> becomes a plain class (no interface), IRequestHandler<T> becomes a class with a Handle method, and IPipelineBehavior<T> becomes a Wolverine middleware. The Wolverine documentation includes a dedicated MediatR migration guide that covers the mechanical transformation step by step.

Moving from MediatR to Brighter is more structural. Commands inherit from Command, handlers implement RequestHandler<T, TResponse>, and pipeline behaviors become handler decorators. Teams should budget for a non-trivial refactoring pass if the codebase is large.

In both cases, start with a single bounded context or service, validate the pattern in production, and then roll out progressively. Avoid a big-bang migration.

☕ Prefer a one-time tip? Buy us a coffee — every bit helps keep the content coming!

FAQ

Is MediatR still free to use in .NET projects? The current stable version of MediatR remains available under the Apache 2.0 license. However, Jimmy Bogard has announced plans to introduce commercial licensing for future major versions. Teams building on MediatR today should monitor the licensing status before upgrading to future major releases, particularly for production enterprise deployments.

What is the main advantage of Wolverine over MediatR? Wolverine's primary advantages are its unified in-process and distributed messaging model, significantly lower dispatch latency through source-generated pipelines, and built-in support for outbox patterns, sagas, and scheduled messaging. MediatR is in-process only and relies on reflection for handler dispatch.

Can I use Wolverine without Marten or the Critter Stack? Yes. Wolverine can be used as a standalone mediator for in-process dispatch without any dependency on Marten or PostgreSQL. You only need Marten (or another Wolverine storage provider) if you want durable outbox messaging, saga persistence, or scheduled job storage.

Is Brighter production-ready for enterprise .NET applications? Brighter is a mature, production-hardened framework that has been used in enterprise systems since 2014. It supports a wide range of message brokers, includes built-in resilience primitives, and has strong OpenTelemetry integration. It is well-suited for enterprise environments that need portability, observability, and explicit, governed patterns.

Should I migrate from MediatR to Wolverine or Brighter today? Not necessarily. If MediatR is working and your system requirements are in-process only, migration has a cost that may not be justified by a benefit. Evaluate migration if you are starting a new service, have identified distributed messaging requirements, or have performance bottlenecks attributable to MediatR's reflection-based dispatch. For brownfield migrations, use a bounded context as a pilot before committing to a full switch.

What happens to the CQRS pattern if I switch to Wolverine? The CQRS pattern maps cleanly onto Wolverine. Commands and queries are plain classes, and Wolverine resolves the handler by type. Pipeline middleware handles cross-cutting concerns. The conceptual model is identical to MediatR — the difference is in how handlers are discovered (convention vs. interface) and how the dispatch pipeline is compiled (source gen vs. reflection).

Does Brighter support .NET 10? Brighter maintains active compatibility with current .NET LTS and STS releases. Check the official Brighter GitHub repository and release notes to confirm compatibility with .NET 10 at the time of your evaluation, as minor version updates are released on a regular cadence.