Marten 9.0, Polecat 4.0, and Wolverine 6.0 are Live!

The JasperFx AI Skills are already updated with content to help you upgrade quickly to our new versions.

The Critter Stack 2026 releases that I first mentioned a couple weeks ago have all hit Nuget — and in some cases might already have bug fix or even a small enhancement release since that major version release. It’s not a huge release at all, but it helps makes systems built with the Critter Stack tools potentially more performant, puts the technical foundation in a bit better place, and positions our tools to be much more usable within Serverless scenarios.

The major goals of this release wave have been to:

• Optimize the “cold start” time of both Marten and Wolverine (Polecat was purposely built with somewhat different internals and less flexibility than Marten to have an optimized cold start time from the get go) with the goal of making the tools better for Serverless applications, dynamic scaling, and just having faster cycle times in local development
• Believe it or not (I was pleasantly surprised), it’s now possible to compile applications using Marten, Polecat, and/or Wolverine with AOT compliance (there’s a catch or two of course)
• Reduce the technical duplication between Marten and Polecat with the hopes of having less code to support in general and improving Polecat’s usage by relying more on proven internals from the much older Marten
• Smuggle in a lot of new observability in the internals for CritterWatch usage soon
• Establish what had been recommended “opt in” configurations as the new defaults for better greenfield development with Wolverine and especially Marten

I don’t have final numbers, but there was an attempt to make some performance improvements to the internals of all the tools along the way. I’ll publish some benchmarking by the end of this coming week.

There will inevitably be problems with these new releases — and there’s already been a couple reports related to the projection changes in Marten that have been addressed so far. My attitude about this never ending stream of bug reports is summed up by the great philosopher of my youth, Vanilla Ice:

“If there was a problem, yo I’ll solve it” (or Babu or Anne or someone else active in the community will).

I’ve got to tell you that I love that the open issue and pull requests count across the entire Critter Stack is very low (single digits as I write this) and I’d like to keep it that way going forward, so we’ll just try to jump on whatever comes in.

Alright, on to some details:

Marten 9.0

The first change and most important change is that Marten 9.0 completely eliminated all usage of the runtime code generation that Marten has used since the 4.0 release in 2021. There’s still just the tiniest bit of FastExpressionCompiler usage for being able to read or write identity values to persisted types, but no other code generation. That’s where the cold start improvement happened for Marten 9.0. That also got us a lot farther along to the AOT compliance.

The conventional projections like this:

public sealed record QuestParty(Guid Id, List<string> Members)
{
    // These methods take in events and update the QuestParty
    public static QuestParty Create(QuestStarted started) => new(started.QuestId, []);
    public static QuestParty Apply(MembersJoined joined, QuestParty party) =>
        party with
        {
            Members = party.Members.Union(joined.Members).ToList()
        };
    public static QuestParty Apply(MembersDeparted departed, QuestParty party) =>
        party with
        {
            Members = party.Members.Where(x => !departed.Members.Contains(x)).ToList()
        };
    public static QuestParty Apply(MembersEscaped escaped, QuestParty party) =>
        party with
        {
            Members = party.Members.Where(x => !escaped.Members.Contains(x)).ToList()
        };
}

Got a maybe significant performance boost as we adopted a purely source generator approach around the conventional methods in place of our previous FastExpressionCompiler approach that didn’t build up the most efficient possible code by any means (FEC was not the problem by any means). Your experience will vary of course, and I expect that to probably be the biggest issue with the release just because of the sheer possible permutations of usage, but I think these changes will ultimately be beneficial for performance.

Marten 9.0 also adjusted some of the out of the box defaults and corrected what I think is “Marten’s original sin” (identity map enabled by default) when we were purposely building Marten at first as a drop in replacement for an existing tool way back when. The big changes are:

1. Lightweight sessions (no identity map) are now the Marten default. If you’re building a greenfield system or follow “Critter Stack” best practices and idioms, you’ll see a small performance improvement. If you have very deep call stacks where the same Marten session is getting reused at different times and possibly loading the same entity multiple times, you may want to explicitly enable identity sessions by default.
2. The event store append mode is “quick append with server timestamps” by default. The performance and even reliability benefits are so great that we made this the new default

See this section of the migration guide for more information.

There is a set of new features coming for Marten in the next week around truly massive scalability of the event store for a JasperFx Software client but I didn’t want to hold up the Marten 9.0 release for that other than making some internal changes that will enable what we’re going to try to do.

Polecat 4.0

Polecat 4.0 benefits from all of the shared changes in the projections library with Marten and now shares far more internal guts with Marten. Polecat 4.1 that should be out before you read this post will also tighten up some error handling to be more consistent with proven patterns in Marten.

Wolverine 6.0

Wolverine 6.0 was a smaller release in terms of what users will notice. The release mostly revolved around the changes in the underlying dependencies, the AOT compliance, and cold start improvements. The runtime code generation with Roslyn is still there (and not going anywhere folks, not without Wolverine becoming a completely different tool anyway), but the JasperFx.RuntimeCompiler can now be just a development time dependency if you want so that you can have a much smaller deployed image. This again is part of the long standing plan to get around to having a better Serverless story for Wolverine.

I also smuggled in quite a bit of extra observability meant for CritterWatch, and we’ll hopefully show that off soon!

There’s a couple features still in the back log, with maybe an upcoming integration with job schedulers like Quartz.Net or TickerQ. Then a much bigger story for improving the usability of Wolverine with F# (more or less, being able to generate F# code instead of C# code).

JasperFx and Weasel

The baseline JasperFx, JasperFx.Events, and their related source generators flipped over to 2.0. Again, the goals where AOT compliance and improvements to the source generators for Marten & Polecat’s projection support. There was quite a bit of work smuggled into this layer as well for CritterWatch.

Weasel 9.0 did go through an effort to reduce code duplication across the different database engines that it supports, but otherwise just dropped .NET 8.0 and added a little bit of work meant for CritterWatch down the line (dynamic tenancy management).