MassTransit with RabbitMQ and Azure Service Bus: Is It Worth a Commercial License?

A toll road or a free highway?

Imagine you drive a delivery van every day. For years you used a free highway. It was good enough. Then one morning a sign appears: "From next month, this road becomes a toll road." You now have a choice. You can pay the toll and keep using the smooth, well-kept road. Or you can take the older free road that still exists but gets less care over time. Or you can find a different highway run by someone else, also free, but newer and not as familiar.

This is exactly the question .NET teams face with MassTransit today. For years it was a free, open-source library that made messaging between services easy. From version 9 it became a commercial product. The old free version (v8) still works, but it will get less attention over time. And there are other "free highways" like Wolverine and Rebus.

In this post we will look at what MassTransit does, how it works with RabbitMQ and Azure Service Bus, what the new license costs, and the big question: is it worth paying for?

What MassTransit actually does

When you split one big app into many small services, those services need to talk. They do not call each other directly with phone calls (HTTP). Instead they drop letters into a post office and walk away. The post office holds the letter safely and delivers it when the other service is ready. That post office is a message broker — RabbitMQ or Azure Service Bus.

The problem is that each broker speaks its own language. RabbitMQ has exchanges and queues. Azure Service Bus has topics and subscriptions. Writing raw code for each one is fiddly and easy to get wrong.

MassTransit sits on top of the broker. It gives you one tidy set of words — publish, send, consume — and quietly does the broker-specific work behind the scenes. You write your code once. You can swap the broker underneath with mostly setup changes.

Think of MassTransit as a friendly translator. You speak one simple language to it. It speaks RabbitMQ to RabbitMQ and Azure-speak to Azure Service Bus. You do not need to learn both.

A tiny message and a consumer

Let us see the smallest possible example. First, a message is just a plain class. It is the letter you send.

// The message: a plain record. No special base class needed.
public record OrderSubmitted
{
    public Guid OrderId { get; init; }
    public string CustomerEmail { get; init; } = string.Empty;
    public decimal Amount { get; init; }
}

Next, a consumer. This is the person at the other post office who opens the letter and acts on it.

using MassTransit;
 
public class OrderSubmittedConsumer : IConsumer<OrderSubmitted>
{
    private readonly ILogger<OrderSubmittedConsumer> _logger;
 
    public OrderSubmittedConsumer(ILogger<OrderSubmittedConsumer> logger)
        => _logger = logger;
 
    public async Task Consume(ConsumeContext<OrderSubmitted> context)
    {
        var order = context.Message;
        _logger.LogInformation(
            "Order {OrderId} for {Email} received",
            order.OrderId, order.CustomerEmail);
 
        // Do the work: save to DB, send an email, etc.
        await Task.CompletedTask;
    }
}

Notice the consumer does not know or care whether the letter came through RabbitMQ or Azure Service Bus. That is the whole point.

Switching the broker is a setup change

Here is where MassTransit earns its keep. The same message and the same consumer run on either broker. Only the wiring in Program.cs changes.

For RabbitMQ you write this:

builder.Services.AddMassTransit(x =>
{
    x.AddConsumer<OrderSubmittedConsumer>();
 
    x.UsingRabbitMq((context, cfg) =>
    {
        cfg.Host("localhost", "/", h =>
        {
            h.Username("guest");
            h.Password("guest");
        });
 
        cfg.ConfigureEndpoints(context);
    });
});

To move to Azure Service Bus, you change the one block that picks the broker:

x.UsingAzureServiceBus((context, cfg) =>
{
    cfg.Host("Endpoint=sb://your-namespace.servicebus.windows.net/;...");
    cfg.ConfigureEndpoints(context);
});

Your consumers, your messages, your business logic — all untouched. This is the freedom from vendor lock-in that people love. You are not married to one cloud.

Publish versus send: two ways to mail a letter

MassTransit gives you two ways to move a message, and it helps to know the difference.

• Send is like posting a letter to one exact address. "Service B, please handle this command." There is one clear receiver.
• Publish is like putting up a notice on a board. "This happened!" Anyone who cares can read it. Zero, one, or many services may react.

You send commands (do this) and you publish events (this happened). Getting this right keeps your services nicely loosely coupled.

Why MassTransit is more than a thin wrapper

If MassTransit were only a translator, the license question would be easy — you would just write the broker code yourself. But it gives you a lot of hard, boring, important plumbing for free:

• Retries. If a message fails, it tries again with a growing delay instead of giving up.
• Error queues. Messages that keep failing are moved aside so they do not block everyone.
• Outbox. It can save the message and your database change together, so you never lose a message after a commit.
• Sagas. Long, multi-step jobs (like an order that touches payment, stock, and shipping) get a clean state machine.
• Scheduling. Delay a message ("remind me in 5 minutes").
• Observability. Built-in OpenTelemetry traces and metrics.

Writing all of this yourself, correctly, takes months and a lot of painful bugs. That is the real value you are weighing against the price.

The change: MassTransit went commercial

Now the part everyone is talking about. The maintainers announced that MassTransit v9 is a commercial, source-available product. Building and supporting a library this big, for free, for years, is a huge amount of unpaid work. Going commercial is meant to fund that work properly.

Here is the timeline in simple terms:

So nobody's existing app breaks. v8 keeps running. The choice only appears when you want new features built after the split, or you want paid support.

What does the license cost?

At launch the published prices looked roughly like this. Treat these as a guide, not gospel — always check the official pricing page before you budget.

One important word in the free tier is "may". The wording says small companies "may qualify". That little word makes lawyers and finance teams nervous, because it is not a flat promise. If your company is near the line, read the actual license text carefully or ask the vendor directly.

For a real business, 4000 to 12000 US dollars a year is often cheap compared to one senior developer's time spent building and maintaining the same plumbing. For a tiny side project or a startup under the revenue line, it may cost nothing at all. The pain is mostly for the middle: companies just over the line who feel the new bill.

So, is it worth it?

There is no single answer. It depends on your situation. Let us reason through it like a checklist.

Lean towards paying for v9 if:

• You already run MassTransit in production and rely on its sagas, outbox, and retries.
• You want a vendor you can call when something breaks at 2 a.m.
• The yearly fee is small next to your engineering payroll.
• Rewriting your messaging layer would be risky and slow.

Lean towards staying on v8 if:

• Your app is stable and you do not need the newest features.
• You are happy to live without paid support until at least end of 2026.
• You want time to think before making a big move.

Lean towards a free alternative if:

• You are starting fresh, so there is no migration cost.
• The license terms genuinely do not fit your budget or your legal comfort.
• You are happy on a newer, smaller library.

The free alternatives, briefly

If you decide MassTransit v9 is not for you, you are not stuck. The .NET world has good options.

Wolverine is the name you will hear most often as the free replacement. It is MIT-licensed and quite fast. But remember the toll-road lesson: a free road can mean you do more of the upkeep yourself. Younger libraries may have fewer guides, fewer Stack Overflow answers, and a smaller team behind them. "Free" is never truly free — you pay in your own time and risk instead.

A quick word on related libraries

You may have heard that MediatR also went commercial around the same time, from the same maintainer. MediatR is an in-process tool (it routes calls inside one app), while MassTransit is for messages between apps over a broker. They solve different problems, but both moving to paid models is part of the same bigger story: popular free .NET tools are looking for ways to be sustainable. It is a healthy thing in the long run, even if the change feels uncomfortable at first.

A practical migration tip

If you do move off MassTransit, do not try to swap everything in one weekend. Move one consumer at a time. Keep your message contracts (the plain record classes) as stable as you can, since they are the part both sides agree on. Test each step. A calm, gradual move beats a risky big-bang rewrite every time.

// Keep your message contracts in a shared, library-agnostic project.
// Both MassTransit and a future replacement can use the same record.
public record OrderSubmitted
{
    public Guid OrderId { get; init; }
    public string CustomerEmail { get; init; } = string.Empty;
    public decimal Amount { get; init; }
}

Because the contract has no MassTransit-specific code in it, swapping the library underneath becomes far less scary.

Quick recap

• MassTransit puts one simple API over message brokers like RabbitMQ and Azure Service Bus, so switching brokers is mostly a setup change.
• It gives you a lot of hard plumbing for free: retries, error queues, outbox, sagas, scheduling, and tracing.
• v8 is free and open source, and gets security and critical fixes through at least the end of 2026.
• v9 is commercial and source-available. Small companies under 1 million USD revenue may qualify for a free tier; others pay roughly 4000 to 12000 USD a year.
• Whether it is worth paying depends on your situation: existing users who rely on it lean towards paying; brand-new projects can try free options like Wolverine or Rebus.
• Keep your message contracts clean and library-free, so you always have the freedom to switch later.

References and further reading

• Announcing MassTransit v9 — Official Documentation
• MediatR and MassTransit Going Commercial — Milan Jovanović
• MassTransit RabbitMQ and Azure Service Bus: Is It Worth a Commercial License — Anton Dev Tips
• Wolverine for .NET Microservices: The Best MassTransit Alternative?
• MassTransit vs NServiceBus in .NET: 2026 Comparison