At JasperFx Software, we feel like our superpower as software developers is having an unusually long attention span that's allowed us to continuously improve tools like Marten that's coming up on 11 years old and Wolverine that goes back even longer if we include its predecessor tools. Even in mature subsystems that I sometimes tend to think are "done," we still find reasons and ways to improve them in the face of new information.

There's a version of this blog post that's a lot more exciting than the one I'm actually going to write. It has a shiny new feature in the headline, a splashy API you've never seen before, and a bunch of exclamation points. This is not that post.

Instead, I want to talk about the least glamorous thing a software company can do, which is also -- I'd argue -- the most valuable thing we do at JasperFx: taking mature infrastructure that already works and quietly making it faster, more correct, and more trustworthy, week after week, release after release. "Boring" software -- predictable, dependable, always improving -- is a feature. It is arguably the feature for the kind of foundational libraries the Critter Stack aims to be. Nobody wants their event store or their message broker to be exciting.

We just closed out a stretch where the Critter Stack got measurably better in a bunch of ways that will never trend on Hacker News. I want to walk through them, because taken together they're a pretty good illustration of how we think about maintaining infrastructure that real companies bet their businesses on.

The cadence, and why it matters

We are very conscious of how rapid our release cadence is right now and know that it can be daunting for some users

First, some raw numbers. In roughly three weeks we shipped dozens of releases across the stack. Marten rolled up to 9.16. Wolverine got to 6.22. Weasel reached 9.18, Polecat hit 5.2, and the shared JasperFx core libraries that everything else builds on climbed to 2.31.

That's not a release train we run for its own sake. Frequent, small releases are a discipline: they keep the blast radius of any single change tiny, they get fixes into your hands in days instead of quarters, and -- honestly -- they force us to keep the whole stack in a continuously shippable state. A project that only cuts a release every six months is a project that spends the week before every release terrified. We'd rather ship on Tuesday, notice something on Wednesday, and ship again on Thursday.

We already did a straight-up roundup of the late-June wave over in "A Big Week for the Critter Stack," so I'm not going to re-list changelogs here. What I want to do instead is pull out five workstreams from July that show what continuous improvement actually looks like when you get down in the weeds.

Owning the subtle correctness bugs

The first two are correctness fixes in Marten's async projection subsystem (which Jeremy had erroneously thought was as good as it was ever going to get), and they're exactly the kind of bug that separates infrastructure you can trust from infrastructure you merely hope works.

The async projection daemon relies on "high water detection" to know how far it can safely process events. We found a subtle case where the daemon could advance the "high water mark" past an event that was still held inside an in-flight transaction -- which, if you follow the implications, means a projection could skip an event that hadn't actually committed yet. That is precisely the sort of once-in-a-blue-moon, impossible-to-reproduce-on-your-laptop bug that erodes trust in an event store. We tracked it down, we own it, and we fixed it. I wrote up the whole thing in Never Skip an Event: Fixing Marten's High Water Detection.

The related second fix is almost more embarrassing to admit, and therefore more important to talk about. We had a health check that would happily report a stuck projection daemon as "Healthy." Your projections could be silently wedged and dead in the water, and your monitoring dashboard would show a cheerful green light. We added a proper high-water health check to both Marten and Polecat that actually catches this condition. If you're running the async daemon in production, this is the health check you didn't know you were missing -- details in A Health Check That Actually Catches a Stuck Projection Daemon.

Neither of these is a feature. Both of them are the difference between "it works in the demo" and "it works at 3am on a Saturday under load."

Performance work you can actually prove

Wolverine's durable messaging got a serious performance pass, and I want to be precise about what we measured and how. We build our benchmarks with a twin-harness rig that runs Wolverine's durable transports head-to-head against the raw client libraries -- Confluent.Kafka, RabbitMQ.Client -- so the comparison is honest about what Wolverine's durability and reliability guarantees actually cost you versus talking to the broker by hand.

Along the way that rig surfaced a genuinely nasty bug: a low-throughput latency problem in the sender batching logic. When message volume was low, p50 latency was sitting at an ugly 5.8 seconds. Once we found and fixed the batching behavior, that dropped to 136ms. That's not a rounding-error improvement; that's a bug that would have quietly made low-traffic systems feel broken. On the throughput side, durable messaging came out +83% on Kafka and +186% on RabbitMQ against the same baselines. The full methodology, the harness design, and the numbers are all in Wolverine Durable Messaging: Chasing Down Latency and Throughput.

The point I keep coming back to internally is that performance claims are worthless without a repeatable rig behind them. Anyone can post a benchmark that makes their own library look good. Comparing against the raw broker clients, with a harness we're willing to describe in public, is how we keep ourselves honest.

The fourth workstream is quieter but adds up over time: we taught Marten's LINQ provider to translate more query patterns directly into PostgreSQL instead of pulling rows back and finishing the work in client-side C#. Every query we can push down into the database is less data over the wire and less work in your process. I dug into some of the specifics in Smarter Marten LINQ: Pushing More Work Into PostgreSQL.

The unglamorous foundation

The fifth workstream is the most "infrastructure for the infrastructure" of the bunch. Weasel -- the schema management library that started life buried inside Marten -- has been maturing into the shared, dialect-neutral schema engine for the entire stack. Consolidating schema management into one well-tested engine means every database feature we harden benefits Marten, Wolverine, and Polecat at once instead of being reimplemented three times. And as a nice bonus of getting Weasel to a solid, dialect-neutral place, it can now generate EF Core migrations too. If you want the tour, start with Meet Weasel, the Critter Stack's Schema Engine and then Generate EF Core Migrations with Weasel.

Boring is the whole point

Step back and look at the shape of the last few weeks: two subtle correctness fixes, a health check that finally tells the truth, a latency bug caught by a real benchmark rig, a broad throughput win we can prove, smarter query translation, and a foundational library growing up. Not one of those is a headline feature. All of them make the stack a little faster and a little more correct underneath the applications you've already shipped.

That's the deal we're trying to offer. You shouldn't have to think about your event store or your message bus. It should just keep getting better while you sleep.

And that steady, unglamorous hardening is exactly what a JasperFx support contract buys you -- not a promise of shiny new toys, but a stack that measurably gets faster and more correct over time, with the people who wrote it a message away. If you want to watch this work happen in the open, or bring us a problem of your own, come find us in Discord. We're always in there arguing about the next boring improvement.