Right before heading into a short vacation, I wanted to blog about some of our recent releases this past week as the entire CritterStack has been busy lately. Between June 22 and June 29, we shipped three Wolverine releases, three Marten releases, and three Polecat releases — a week heavy on database-backed messaging, brand-new interoperability with the rest of the .NET messaging ecosystem, and a steady drumbeat of work to make every part of the stack more observable and more manageable from CritterWatch.

Here’s a tour of what landed.

Release Timeline

CritterWatch Beta 1

The big win for the week is (finally) getting out the first CritterWatch 1.0 beta, which I finally managed to present in a live stream yesterday. And while there’s a lot further to go for a true, quality 1.0 release, I think it’s showing a lot of promise and will add quite a bit of value for Critter Stack users at both development and production time.

There’s also several new sample solutions at https://github.com/JasperFx/CritterStackSamples/tree/main/critterwatch that show little fake systems stood up with CritterWatch and Aspire using several permutations of Rabbit MQ, AWS SQS, Azure Service Bus, SQL Server, and PostgreSQL — including the new embedded model.

Wolverine

Three releases this week, but the headline is clear: database-backed messaging got faster, and Wolverine now has more options for interoperability with NServiceBus and MassTransit. Both of these improvements were client requests for JasperFx Software.

🚀 Database queue performance

Both the PostgreSQL and SQL Server transports got performance improvements, with the SQL Server work being quite a bit more important, but with a new opt in option so that existing users won’t be surprised by database migrations.

On SQL Server the new optimization is one fluent call. Clustering the queue and scheduled tables on a monotonic seq identity (instead of the previous random-Guid clustered key) turns FIFO dequeue into a clustered seek with physically contiguous deletes:

opts.UseSqlServerPersistenceAndTransport(connectionString)
    .OptimizeQueueThroughput()

The raw-DDL benchmark behind the PR tells the story — same hardware, same workload:

If you lean on Wolverine’s database queues — whether as a no-broker option or to keep messaging transactionally consistent with your business data — the indexed dequeue path is a free win on upgrade. OptimizeQueueThroughput() is opt-in specifically because enabling it on an existing database triggers a one-time queue-table rebuild, so it’s a maintenance-window change for existing systems and a no-brainer for new apps.

📖 SQL Server transport docs · 📖 PostgreSQL transport docs

🆕 Interop with MassTransit and NServiceBus over SQL Server and PostgreSQL

Wolverine already has quite a few options for interoperability with pre-canned recipes for both NServiceBus and MassTransit against all the major message brokers, but we had a client request to do the same with NServiceBus and SQL Server, so we just beefed up all the permutations while we had the hood up. Wolverine can now send to and receive from MassTransit and NServiceBus applications using each framework’s own SQL Server or PostgreSQL queueing — reading and writing their native tables directly, no shared broker required.

Landed across 6.14.0 and 6.16.0:

• NServiceBus over SQL Server (#3198)
• NServiceBus over PostgreSQL (#3201)
• MassTransit over PostgreSQL (#3203)
• Each interop transport is pinned to a dedicated database under multi-tenanted storage (#3271), Seq is indexed on the NServiceBus PostgreSQL queue table (#3205), and a shared DatabaseListener base now backs the polling loop across all of these (#3206).

For NServiceBus, Wolverine reads and writes the NServiceBus queue tables directly — one table per queue with a JSON Headers column and a raw Body column:

using Wolverine.SqlServer.Transport.NServiceBus;
builder.UseWolverine(opts =>
{
    // Wolverine's own durable inbox/outbox still lives in SQL Server
    opts.PersistMessagesWithSqlServer(connectionString, "wolverine");
    opts.UseNServiceBusSqlServerInterop();
    // Publish to an NServiceBus endpoint's queue table
    opts.PublishMessage<OrderPlaced>().ToNServiceBusSqlServerQueue("nsb");
    // Listen to Wolverine's own queue table and use it for replies
    opts.ListenToNServiceBusSqlServerQueue("wolverine").UseForReplies();
    // Bind NServiceBus interface-typed messages to Wolverine's concrete types
    opts.Policies.RegisterInteropMessageAssembly(typeof(IOrderContract).Assembly);
})

PostgreSQL is identical with the UseNServiceBusPostgresqlInterop() / ListenToNServiceBusPostgresqlQueue() / ToNServiceBusPostgresqlQueue() trio. MassTransit is a different shape — its SQL transport is a function-driven, two-table model (transport.message + transport.message_delivery) that MassTransit owns and migrates, so Wolverine calls its stored functions rather than touching a table:

using Wolverine.Postgresql.Transport.MassTransit;

builder.UseWolverine(opts =>
{
    opts.PersistMessagesWithPostgresql(connectionString, "wolverine");

    opts.UseMassTransitPostgresqlInterop(autoProvision: true);

    opts.PublishMessage<OrderPlaced>().ToMassTransitPostgresqlQueue("masstransit");
    opts.ListenToMassTransitPostgresqlQueue("wolverine").UseForReplies();

    opts.Policies.RegisterInteropMessageAssembly(typeof(IOrderContract).Assembly);
});

These join the existing Amazon SQS interop options (which also picked up two bug fixes this week, #3190) and a fix to map Wolverine’s TenantId from incoming MassTransit messages (#3192). The practical upshot: you can introduce Wolverine into an existing MassTransit or NServiceBus shop incrementally, service by service, over infrastructure both sides already trust.

📖 Interop with NServiceBus over database transports · 📖 Interop with MassTransit over database transports

🔭 Observability & health

Okay, so big parts of this are AI written and you don’t care much about the details. Just take my word for it that all this mumbo jumbo means that CritterWatch can “see” and report back to you much more about how your system is running, what your system actually is, and we’ve added more robustness to monitoring and kick starting external transport listeners.

A large share of the week’s Wolverine work exists to make running systems legible — much of it surfaced directly through CritterWatch:

• A shared BackgroundReceiveLoop with receive-loop health reporting, now adopted across SQS, Redis, the PostgreSQL queue, the SQL Server queue, and Kafka (#3236).
• Transport connection state surfaced in EndpointHealthSnapshot, with a new IReportConnectionState implemented for NATS, MQTT, Pulsar, and Redis (#3231), plus a force-restart path for stuck listeners (#3232).
• A sanitized, credential-free broker connection summary on BrokerDescription (#3272) — so the dashboard can show you where a broker points without ever leaking secrets.
• Richer metrics: every instrument tagged with a source service name (#3221), dimensional inbox/outbox/scheduled gauges, and configurable histogram buckets (#3224).
• The discovered gRPC endpoint manifest is now exposed via a ServiceCapabilities descriptor source (#3268, #3266), and RabbitMQ sending endpoints are now properly named in health snapshots (#3273).

📖 Instrumentation and Metrics · 📖 Diagnostics

🐛 Reliability fixes & Pulsar

We did a big round of improvements for Kafka a couple weeks ago to open up more Kafka idioms to Wolverine users. Later though, we did the exact same thing for Wolverine’s Pulsar support.

6.14.0 also closed out a major Pulsar re-evaluation effort — DLQ/retry precedence, initial subscription position, multi-topic and regex subscriptions, native per-message redelivery, acknowledgment-strategy choice, a Reader interface for bounded replay and non-durable hot-tail, a tiered retry-letter error policy, producer deduplication, and both JSON and Avro schema support with broker-side registration (#3194–#3215).

Two of those are worth showing. Pulsar’s defining feature is broker-side schema registration and compatibility checking — now a single fluent call, with the message body still owned by Wolverine’s serialization:

opts.PublishMessage<OrderPlaced>()
    .ToPulsarTopic("persistent://public/default/orders")
    .UseJsonSchema<OrderPlaced>();   // or UseAvroSchema<T>() for Avro on the wire

And the new tiered retry-letter policy — the Pulsar analogue of the Kafka transport’s MoveToKafkaRetryTopic — expresses native redelivery delays as a first-class, discoverable error policy:

// On failure: redeliver after 5s, then 30s, then 2m, then dead-letter.
opts.OnException<TransientException>()
    .MoveToPulsarRetryTopic(5.Seconds(), 30.Seconds(), 2.Minutes());

📖 Pulsar schema support · 📖 Tiered retry-letter policy · 📖 Producer deduplication

Plus targeted reliability fixes: a RabbitMQ agent that could latch Disconnected after a channel-only shutdown (#3187), stable node identity for storeless Solo hosts (#3189), and re-attaching the sender wire tap to recovered envelopes (#3276).

Polecat — Making It More Robust

Polecat is finally getting some serious people using it, and that has inevitably meant that more issues are arising. While the Critter Stack team can certainly not claim to be perfect in our delivery, I’ll swear up and down that we’re the most responsive team of maintainers in .NET and we’ve been turning around Polecat issues fast to get that thing as robust as possible for our early users. Polecat is also moving pretty fast because I’m making a big deal of ensuring that all CritterWatch features for Event Sourcing or the Document Database features are fully supported for Polecat, and that’s generated a lot of recent work in Polecat as well.

Polecat shipped three releases this week (4.5.2, 4.6.0, 4.7.0), and the through-line is hardening: fewer sharp edges, more parity with Marten’s behavior, and a real document-metadata story.

🛡️ Robustness & correctness fixes

• Repopulate the natural-key lookup table on projection rebuild (#261) — rebuilds no longer leave natural-key lookups stale (mirrored by the same fix in Marten, below).
• Patch().Set() now honors EnumStorage (#264) and supports DateTime/DateTimeOffset/DateOnly/TimeOnly (#265).
• Sequential GUIDs for auto-assigned document ids (#245) — far friendlier to index locality than random GUIDs.
• AsString enum LINQ predicates honor the JsonNamingPolicy (#224), computed-column indexes are usable by the LINQ translator (#225), on-the-fly event-store schema creation and InitialData seeding work on startup (#233), and IEventStore.Identity now varies by StoreName so multiple stores stay distinct (#208).

🆕 Document Metadata

I found this gap during CritterWatch development:(

A genuinely new capability area: opt-in document metadata, end to end — mirroring Marten’s metadata model so the two stores behave alike. Enable the columns you want with a fluent DSL (or attributes) (#251, #252):

opts.Schema.For<Order>().Metadata(m =>
{
    m.LastModifiedBy.Enabled = true;
    m.CorrelationId.Enabled = true;
    m.CreatedAt.MapTo(x => x.CreatedDate);   // project a column onto your own member
})

Then read just the metadata for a row — no document body deserialization — via the new MetadataForAsync<T> API (#253):

 metadata = await session.MetadataForAsync(order);
// metadata.Version, .LastModified, .LastModifiedBy, .CorrelationId, .CausationId, ...

Rounding it out: an opt-in user_name (LastModifiedBy) event-metadata column (#248), auto-seeding of CorrelationId/CausationId from Activity.Current on session open (#250), and session-level Headers with SetHeader/GetHeader (#249).

🔭 Observability & CritterWatch

• An opt-in polecat.event.append OpenTelemetry counter (#247) and runtime event-append observations via IEventStoreInstrumentation.AppendObserver (#215).
• IDocumentStoreDiagnostics with an enriched mapping descriptor (#210), structured partitioning in the DocumentMappingDescriptor (#214), and metadata capabilities + an IEventStore bridge with tenant-scoped document diagnostics (#254) — the same descriptor surface Marten exposes, so CritterWatch sees Polecat stores the same way it sees Marten.

🆕 Range partitioning

This came from CritterWatch integration as well.

Declarative range partitioning for document tables (#257, #212), now with a Marten-parity fluent surface — the classic time-series retention pattern:

// Marten manages the boundaries:
opts.Schema.For<MetricsSample>().PartitionOn(x => x.BucketEnd).ByRange(jan, feb, mar);
// Or let a DBA / pg_partman own SPLIT/SWITCH/DROP at runtime for retention:
opts.Schema.For<MetricsSample>().PartitionOn(x => x.BucketEnd).ByExternallyManagedRange(jan, feb)

ByExternallyManagedRange(...) provisions the partitions once and then never reconciles them, so a later schema apply won’t clobber the months your retention job has been splitting and dropping.

📖 Wolverine + Polecat integration guide · 📦 Polecat on GitHub

Marten

Three releases (9.10.0, 9.11.0, 9.12.0), with a mix of concurrency-hardening, new partitioning options, and — again — observability work feeding CritterWatch.

🐛 Concurrency & correctness

• Close the mt_events_sequence gap on concurrent Quick OCC failures (#4771) — a first contribution from @KMDjkb. Under truly concurrent FetchForWriting + Quick-append writes to the same stream, a losing transaction could burn a sequence value it never rolled back, leaving a permanent gap that stalls the async daemon’s high-water mark. A new opt-in option takes a FOR UPDATE lock in the OCC path so the loser blocks and raises a clean concurrency error before consuming a sequence value — no schema migration required:opts.Events.UseExclusiveLockOnConcurrentAppends = true;
• Fix a false ConcurrencyException from non-RETURNING event ops in a batched SaveChanges (#4784).
• Repopulate mt_natural_key on projection rebuild (#4793) — the Marten side of the same natural-key fix that landed in Polecat.

🆕 Partitioning & queries

• Range-partition a document table by a non-tenant date column (#4780) — the PartitionOn(member, cfg) API already existed; a Weasel 9.3.0 fix makes the date-keyed retention path stable across deployments and time zones (partition bounds are now compared by normalized instant rather than raw SQL literal, so migrations no longer report a spurious destructive rebuild).
• Metadata-filtered document and event queries (#4792) — the diagnostics surface can now filter documents and events by correlation_id / causation_id / last_modified_by, honored only when the store actually captures that metadata column.

📖 Document storage & date range partitioning · 📖 Document & event metadata

🔭 Observability & CritterWatch

• IDocumentStoreDiagnostics with an enriched mapping descriptor (#4776) and populated event/document metadata capabilities with tenant-scoped document diagnostics (#4790).
• Runtime event-append observations via IEventStoreInstrumentation (#4783) and an exact-identity DeleteProjectionProgressByShardNameAsync for surgical projection-progress management (#4786).

The Common Thread

Three themes ran through all nine releases this week:

1. Database-backed messaging matured — Wolverine’s PostgreSQL and SQL Server queues got faster, and now interoperate directly with MassTransit and NServiceBus over the same databases.
2. Polecat got tougher — a stack of correctness fixes, sequential GUIDs, a full document-metadata story, and range partitioning.
3. Everything got more observable — diagnostics descriptors, instrumentation hooks, OpenTelemetry counters, connection-state reporting, and credential-safe broker summaries across Wolverine, Marten, and Polecat — all converging on a single, consistent surface for CritterWatch to manage.

While Polecat is pretty new, it’s based on over a decade of experience and usage patterns established by the Marten library (and also shares a ton of common infrastructure code as well). Polecat is also backed up by JasperFx Software and we’re available for either consulting or support agreements for Polecat usage.

If you’re a .NET developer, it’s pretty likely your default choice of database at work is SQL Server. If you follow technical content on LinkedIn or reddit from the .NET community, you’re absolutely bombarded with a deluge of content about EF Core with a smattering of Dapper. All of that content assumes that you’re using SQL Server as a relational database paired with an object-relational mapper (ORM) like Entity Framework Core — and all the mapping ceremony, migration scripts, and impedance mismatch that comes along for the ride.

A decade ago some friends and I set out to escape a lot of that friction with Marten, which turns PostgreSQL into a rock-solid document database and event store for .NET. Marten has been running in production systems since the fall of 2016. And while not every system is a great fit for a document database, the Marten community has been able to be far more productive than they would be using an ORM with PostgreSQL where a document database fits. The one persistent question we got from the .NET community the whole time was some variation of: “This is great, but my shop is a SQL Server shop. Can I have this on SQL Server?”

Now you can. Polecat is a new member of the “Critter Stack” that brings the same document database (and event sourcing) developer experience to SQL Server 2025 — taking direct advantage of SQL Server 2025’s brand new native json data type. If you know Marten, you already know Polecat; the public API surface intentionally mirrors Marten so the patterns and muscle memory carry straight over. If you’ve never touched Marten, this post is a gentle introduction to what a document database can do for your productivity.

Show Me the Whole Thing First

Before we break it down, here’s a complete, runnable console application — top-level statements, nothing hidden. Create a new console project, add the Polecat NuGet package, point it at a SQL Server 2025 instance, and run it. There’s no migration step and no mapping file to write first; this is the whole program.

// Program.cs
using Polecat;

const string connectionString =
    "Server=localhost,1433;Database=app;User Id=sa;Password=P@55w0rd;Encrypt=False";

// 1. Spin up the document store. In its default development settings it will
//    create any missing tables on demand the first time it needs them.
await using var store = DocumentStore.For(connectionString);

// 2. Write a couple of documents in a single ACID transaction.
await using (var session = store.LightweightSession())
{
    session.Store(new Customer { Region = "West Coast", Name = "Acme, Inc." });
    session.Store(new Customer { Region = "East Coast", Name = "Initech" });
    await session.SaveChangesAsync();
}

// 3. Query them right back with LINQ — this queries *inside* the JSON column.
await using (var query = store.QuerySession())
{
    var westCoast = await query
        .Query<Customer>()
        .Where(x => x.Region == "West Coast")
        .OrderBy(x => x.Name)
        .ToListAsync();

    foreach (var customer in westCoast)
    {
        Console.WriteLine($"{customer.Name} ({customer.Region})");
    }
}

// A plain POCO. No attributes, no DbContext, no mapping. Just a class.
public class Customer
{
    public Guid Id { get; set; }
    public string Region { get; set; }
    public string Name { get; set; }
}

Run that and you’ll see Acme, Inc. (West Coast) print to the console — and if you peek at the database, you’ll find a pc_doc_customer table that you never asked anyone to create. No mappings, no database migrations, nothing but just getting stuff done!

The rest of this post is just explaining why each of those steps was so short.

A Quick Start

To get going, all you really need is a connection string to a SQL Server 2025 database. SQL Server is very Docker-friendly, which makes it a great choice for local development and disposable test databases.

Here’s the absolute simplest “hello world.” Say I have a plain old C# class for a customer:

public class Customer
{
    public Guid Id { get; set; }
    public string Region { get; set; }
    public string Name { get; set; }
}

Now let’s persist one and read it back:

using Polecat;

await using var store = DocumentStore.For(
    "Server=localhost,1433;Database=app;User Id=sa;Password=...;Encrypt=False");

var customer = new Customer
{
    Region = "West Coast",
    Name = "Acme, Inc."
};

await using var session = store.LightweightSession();
session.Store(customer);
await session.SaveChangesAsync();

// ...and later, load it right back into the same shape
var loaded = await session.LoadAsync<Customer>(customer.Id);

That’s the whole thing. Two facts about that little sample are worth slowing down on, because they’re the entire pitch:

1. We didn’t do any mapping. There’s no DbContext, no OnModelCreating, no fluent configuration, no attributes, nothing telling Polecat how to flatten Customer into columns. We just wrote a class.
2. We didn’t create any database structure. We never wrote a CREATE TABLE, never authored a migration, never ran a script. In its default “just get things done” settings, Polecat detects that the table for Customer doesn’t exist yet and quietly builds it out for us the first time we read or write one.

Polecat is using JSON serialization to persist the data. As long as your type can round-trip to and from JSON, Polecat can store it and load it. That’s it — that’s the contract.

What’s a Document Database, and Why Should You Care?

A document database lets you store and retrieve whole object graphs — “documents” — almost always as JSON, where the database lets you marshal objects in your code straight to storage and query them right back into the same structures later.

The payoff is that you get to code much more productively because you just don’t have nearly as much friction as you do with object-relational mapping, whether that’s wrangling an ORM or hand-writing SQL and mapping code. You don’t have to maintain a parallel relational schema that’s a slightly-wrong reflection of your domain model. You don’t have to keep a stack of migration scripts in lockstep with every property you add. You design the class you actually want, and you store the class you actually want.

If you’ve spent any real time with EF Core, the contrast is stark. With EF Core you’re maintaining a mapping layer: configuring keys, owned entities, value conversions, navigation properties, and a migration history table — all so that a relational schema can approximate your object model. With Polecat there is no mapping layer to maintain. The document is the model.

The SQL Server 2025 Native json Type

Here’s where Polecat gets to lean on something genuinely new. Earlier document-on-SQL-Server attempts had to shove JSON into an nvarchar(max) column and hope for the best. SQL Server 2025 introduced a real, first-class json data type, and Polecat uses it by default for document bodies.

When you stored that Customer above, Polecat created a table named pc_doc_customer with the document serialized into a native json column called data:

CREATE TABLE [dbo].[pc_doc_customer] (
    [id]            uniqueidentifier  PRIMARY KEY NOT NULL,
    [data]          json              NOT NULL,   -- native SQL Server 2025 JSON
    [version]       bigint            NOT NULL,
    [last_modified] datetimeoffset    NOT NULL,
    [created_at]    datetimeoffset    NOT NULL,
    [tenant_id]     varchar(250)      NOT NULL,
    [dotnet_type]   varchar(500)      NULL
);

That native type isn’t just cosmetic — it’s stored in an optimized internal representation and lets the SQL Server query engine reach inside the JSON efficiently, which is exactly what makes the LINQ querying and indexing below practical instead of a parlor trick.

If you’re on a SQL Server instance older than 2025, Polecat has your back: flip one switch and it falls back to nvarchar(max) storage transparently.

await using var store = DocumentStore.For(opts =>
{
    opts.ConnectionString = connectionString;
    opts.UseNativeJsonType = false; // store JSON as nvarchar(max) on pre-2025 SQL Server
});

Integrating with Your Application

For a real application you’ll want Polecat wired into your IHost and dependency injection container. At this point in the .NET ecosystem it’s more or less idiomatic to use an Add[Tool]() method to integrate tools with your app, and Polecat follows that convention:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddPolecat(opts =>
    {
        opts.ConnectionString = builder.Configuration.GetConnectionString("sqlserver");
    })
    .UseLightweightSessions();

var app = builder.Build();

From there your endpoints and services can inject IDocumentStore to open sessions, or inject an IDocumentSession / IQuerySession directly. A lightweight session is the lean, no-change-tracking workhorse — there’s no dirty checking or identity map overhead unless you ask for it.

You Still Get LINQ

Schemaless storage is great right up until somebody asks you to actually find something. A common worry is that going document-style means giving up real querying. Not here. Because the document body lives in that native json column, Polecat ships a LINQ provider that translates your C# expressions into SQL that queries inside the JSON:

await using var session = store.QuerySession();

var westCoast = await session
    .Query<Customer>()
    .Where(x => x.Region == "West Coast")
    .OrderBy(x => x.Name)
    .Take(25)
    .ToListAsync();

Where, OrderBy / OrderByDescending, Skip / Take, FirstOrDefaultAsync, CountAsync, AnyAsync — the usual LINQ vocabulary works against your documents. There’s even a paged-list helper for the extremely common “page N of these results, and tell me the total count” use case:

using Polecat.Pagination;

var page = await session
    .Query<Customer>()
    .OrderBy(x => x.Name)
    .ToPagedListAsync(pageNumber: 2, pageSize: 20);

// page.TotalItemCount, page.PageCount, page.HasNextPage, ...

…and You Still Get Indexes

It’s not only possible to query within the structured JSON data — you can also add indexes that work inside it, so those queries stay fast as your tables grow. Under the covers Polecat creates a persisted computed column that pulls a value out of the JSON with JSON_VALUE, then builds an ordinary nonclustered index on it. You don’t have to know any of that, though. You just declare the index.

You can do it inline on a property with an attribute:

using Polecat.Attributes;

public class Customer
{
    public Guid Id { get; set; }

    [Index]
    public string Region { get; set; }

    [UniqueIndex]
    public string Email { get; set; }

    public string Name { get; set; }
}

…or in your store configuration with a fluent, strongly-typed API that should feel awfully familiar to Marten users:

await using var store = DocumentStore.For(opts =>
{
    opts.ConnectionString = connectionString;

    opts.Schema.For<Customer>().Index(x => x.Region);
    opts.Schema.For<Customer>().UniqueIndex(x => x.Email);
});

Either way, the computed column and its index are created and kept in sync as part of the same “just works” schema management we’ll talk about next.

“It Just Works” Database Migrations

This is my favorite part, and it’s the thing that genuinely changes how fast you can move day to day.

In its default development settings, Polecat manages your database schema for you. The first time you touch a Customer, Polecat checks the database, sees that pc_doc_customer (and any indexes you declared) are missing, and builds them on demand. There’s no migration step standing between writing a class and running your code. This whole mechanism — schema detection, diffing, and migration — comes from the Critter Stack’s Weasel library that Polecat shares with Marten.

You control how aggressive that is with a single setting:

opts.AutoCreateSchemaObjects = AutoCreate.CreateOrUpdate; // the development default
// AutoCreate.All        — drop & recreate (great for tests)
// AutoCreate.None       — never touch the schema (production-locked)

For production you almost certainly don’t want the app altering schema on a hot path at runtime, so Polecat plugs into the Critter Stack’s stateful-resource model. Add the resource setup on startup and Polecat will reconcile the database schema once, up front, as the host boots:

builder.Services.AddPolecat(opts =>
{
    opts.ConnectionString = connectionString;
});

// provision/migrate all Polecat schema objects as the host starts
builder.Services.AddResourceSetupOnStartup();

The same machinery also drives the command-line tooling, so you can export migration scripts for a DBA to review, or apply changes through your deployment pipeline instead of at runtime. The point is that you get to decide — Polecat never makes “should this app change my production schema?” an accident.

Evolving Your Model Without Fear

Now put the JSON storage and the automatic schema management together, and you get the thing that makes document databases so liberating: your model can evolve at the speed of your code.

Say next sprint the Customer needs a phone number and a signup date:

public class Customer
{
    public Guid Id { get; set; }
    public string Region { get; set; }
    public string Name { get; set; }

    // new this sprint — no migration required
    public string PhoneNumber { get; set; }
    public DateOnly SignedUpOn { get; set; }
}

There is no ALTER TABLE. There is no migration script. There is no dotnet ef migrations add. Because the whole document is stored as JSON, new properties simply start showing up in the JSON the next time you save a customer. Documents written before the change deserialize cleanly — the new properties just come back as their defaults until that record gets re-saved. Compare that to the EF Core loop of “edit the entity, add a migration, review the generated SQL, apply it, hope the data backfill is right.” With Polecat you edit the class and keep going.

That’s the productivity story in a nutshell. The friction that normally sits between “I changed my mind about the model” and “the database agrees with me” mostly evaporates.

But Is It Safe? (Yes — It’s ACID)

A fair objection to a lot of document databases is that you trade away transactional integrity for that flexibility, and end up fighting eventual-consistency bugs. Polecat doesn’t make that trade. It’s built directly on SQL Server, which means it’s fully ACID-compliant. Every SaveChangesAsync() is one transaction. You can batch a whole range of inserts, updates, and deletes across multiple document types and commit them atomically, and an immediate query afterward sees exactly what you’d expect — no “give it a few hundred milliseconds and try again” caveats.

And because Polecat is, at bottom, a (rather fancy) library on top of SQL Server — one of the most widely deployed database engines on earth — adopting it doesn’t mean introducing a new piece of exotic infrastructure your ops team has never seen. You keep your existing SQL Server backups, your existing monitoring, your existing hosting and cloud options, and your existing DBA’s hard-won expertise. Polecat just changes how productively you get to use all of it.

Wrapping Up

Polecat brings the document-database developer experience that Marten users have enjoyed for years to the SQL Server world, built squarely on top of SQL Server 2025’s new native json type. You get to:

• Get started in minutes — a connection string and a POCO, no mapping, no migrations.
• Skip the ORM ceremony — there’s no mapping layer to maintain like there is with EF Core, because the document is the model.
• Store documents in a real JSON column — SQL Server 2025’s native json type, not a stringly-typed nvarchar hack.
• Keep your LINQ and your indexes — query inside the JSON and index inside it too.
• Let schema migrations just work — automatic in development, controlled and explicit in production.
• Evolve your model at the speed of your code — add a property, keep moving.
• Keep ACID transactions and your existing SQL Server investment the entire time.

If your shop runs on SQL Server and you’ve ever envied how fast the document-database crowd seems to move, this is the one for you. Go grab the Polecat NuGet package, point it at a SQL Server 2025 instance, and write a class. That’s genuinely all it takes to get started.

I “officially” went solo with JasperFx Software in June of 2023 at the tender age of 49 because hopefully I’m a late bloomer. I’d of course been planning that specific move for quite some time and idly dreaming of being able to found my own company around my OSS passion projects for decades before that. I’ll be writing up something much more official in the JasperFx Software website next year for our 3rd Anniversary as we also officially launch our CritterWatch commercial tool next week, but I felt like jotting down some personal reflections as I wait on a bevy of CI runs to hopefully turn green.

I’ve stumbled around in my career from “real” engineering (petrochemical plants) to “Shadow IT” to kind of doing skunkworks type work in a huge company before fleeing their attempts to do CMMi and off to a high flying Extreme Programming consultancy. Since then its been a mixed bag of small to medium sized companies either doing consulting or product development. I’ve almost always been either a technical lead or architect or even some kind of “Director of Software Architecture,” but almost never felt particularly invested in my job.

I realized early on that I was always much more passionate about my personal work in whatever OSS development tool I was working on at the time. To that end, I’ve long known that I wanted a job building development tooling but it never quite worked out for me to land with a company that did that. My first big attempt at a big OSS tool for other devs that I thought could lead to eventual opportunities (FubuMVC) was a failure so bad that it put me in a multi-year funk. I’ve also been severely limited by being extremely risk averse, so I never had the guts (or wherewithal) to go solo and make the bet on myself and my portfolio of OSS tools.

I will say though that my times where I was actively mentoring other technical leads or architects was very enjoyable. I should say to anybody that I worked with that sees this that I genuinely enjoyed trying to be a mentor at a couple stops when you had to deal with me as the architecture team lead:) But again, that plays into the theme of “wanting to feel respected” that I didn’t realize was a thing for me until the past decade.

But anyway, flash foward a couple years, and Marten was becoming undeniably capable and successful. A few interactions with other people convinced me that there was a genuine professional opportunity there. At the same time, my previous job was clearly going South as we got all new C-level management from the outside. I fortunately had a once in a lifetime personal opportunity to try to do my own company instead. So here I am, three years into having my own company.

Our new CTO at the time told me directly not to come to a big meeting in our Dallas office because I wouldn’t add any value after I had asked to be involved specifically to meet him in person for the first time. Ouch. I might send him a little thank you note after this for helping give me an unintentional shove into what I really wanted to be doing in the first place!

The big takeaways for me are that I’m working harder than I ever have, but I love what I do most of the time. I especially love getting to roll out of bed knowing that I’m working on my tools and my vision every day — even when I’m helping clients. One other thing I very much appreciate is that JasperFx clients have specifically sought out my company because they wanted me to be involved and respect what I bring to the table. After a long career of not always feeling exactly respected and valued by management types, that’s turned out to be a very positive thing for me.

I’m constantly frustrated as hell at how long everything has taken to get rolling and that certain products still aren’t perfectly out, but also occasionally amazed at how much has gotten done and what the company has been able to achieve if you flip to the glass half full view of things.

The downsides are just that it’s a tremendous amount of stress, I get exhausted from the overhead of having a business, always being worried about where the next clients and the next work is going to come from, and never really feeling comfortable. And of course, I’m an American and our health care system is awful, so the health insurance angle is frequently stressful as it has limited my wife’s career options a little bit now that I don’t have company sponsored health insurance.

Just a warning, unless a topic is personal, I’m going to start mostly writing on the JasperFx Software website to try to drive more traffic there.

Don’t throw exceptions for an entity that isn’t found or a value out of range — fair. But swapping that for Result<T> everywhere just trades one kind of noise for another: wrappers, .Match() calls, discriminated unions in every layer.

With Wolverine, most endpoints skip both:

• [Entity(Required = true)] → your 404
• FluentValidation → a 400 ProblemDetails
• Endpoint stays clean, and the OpenAPI metadata still comes out right — no .Produces() calls, no IResult “mystery meat,” no fake C# discriminator union ugliness

Exceptions still earn their place for real failures — Wolverine turns those into retries, re-queues, and dead-lettering. But error handling shouldn’t be your control flow, and neither should a Result wrapper with idiomatic Wolverine usage.

Less ceremony, less noise. Full write-up with code in the comments 👇

Result Pattern or Exceptions for Errors? Wolverine Lets You Say “Neither”