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”

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).