Why CockroachDB Is the Ultimate “Plan B” for .NET Microservices

Beyond PostgreSQL: How to build C# applications that survive regional cloud outages without manual failover

A practical guide for .NET teams migrating from SQL Server to CockroachDB. Learn schema conversion, CDC strategies, EF Core retries, and how to survive regional outages.

*🔗Available for non-Medium members here. *🌐**

Introduction: The Hidden Single Point of Failure in .NET Systems

You’ve done everything right.

Your .NET microservices use retries with Polly. Your gateways have circuit breakers with YARP. Your APIs scale horizontally in Kubernetes.

And yet — when a cloud region hiccups, your entire system still goes dark.

Why? Because your database is almost always the last, most fragile single point of failure.

Traditional SQL databases were never designed for today’s failure modes: region loss, noisy neighbours, or network partitions. They were extended to cope with them.

CockroachDB takes the opposite approach.

It assumes failure is inevitable and designs for it from day one — while still giving .NET developers what they want most: strong consistency and SQL.

The Traditional SQL Bottleneck in .NET

Why EF Core + “Classic SQL” Breaks at Scale

Most .NET systems rely on SQL Server or PostgreSQL. They work brilliantly — until you need:

1. Multi-region writes without complex replication logic
2. Zero-downtime failover (no 30-second “DNS flip” windows)
3. Horizontal scaling without injecting sharding logic into your C# models

At that point, the database stops being infrastructure and starts leaking into your domain logic. You end up writing region-aware routing and shard keys in your application layer — a clear sign of architectural debt.

What Makes CockroachDB Truly Cloud-Native?

CockroachDB isn’t “Postgres with replicas.” It’s a distributed SQL database that just happens to speak the PostgreSQL wire protocol.

Peer-to-Peer Architecture (No Primary Node)

Every node in CockroachDB is equal.

• Any node can serve reads and writes
• Data is automatically sharded into ranges
• Each range is replicated (typically 3–5 copies)

Lose a node — or even an entire availability zone — and the cluster rebalances itself.

No manual failover. No promotion scripts.

Raft Consensus: Surviving the “Split Brain”

CockroachDB uses the Raft consensus algorithm.

Each data range:

• Elects a leader automatically
• Commits writes only after quorum approval
• Preserves correctness during network partitions

This is why CockroachDB can offer serializable transactions across nodes without corrupting data.

Implementation: Using CockroachDB with EF Core

Because CockroachDB is PostgreSQL-compatible, you can use Entity Framework Core with the standard Npgsql provider.

The key mindset shift is this:

In distributed systems, transaction retries are expected. A retry is not a failure — it’s the database protecting correctness.

Configure a Resilient DbContext

builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseNpgsql(connectionString, npgsqlOptions =>
    {
        npgsqlOptions.EnableRetryOnFailure(
            maxRetryCount: 5,
            maxRetryDelay: TimeSpan.FromSeconds(10),
            errorCodesToAdd: new[] { "40001" } // CockroachDB serialization failure
        );
    }));

This single configuration change removes an entire class of production-only bugs.

The Migration Blueprint: Moving .NET Workloads from SQL Server to CockroachDB

At this point, a natural question arises:

“This sounds great — but how do we actually move off SQL Server?”

Migrating from a monolithic SQL Server instance to a distributed CockroachDB cluster is not a lift-and-shift. It’s a controlled evolution in how your .NET system manages state and transactions.

Below is a practical, battle-tested blueprint.

1. Schema Conversion (MOLT Tooling)

SQL Server and CockroachDB use different SQL dialects and data-type semantics. The fastest way to bridge that gap is CockroachDB’s MOLT (Migrate Off Legacy Technology) tooling.

Key considerations:

• Identifiers SQL Server is case-insensitive by default. CockroachDB is case-sensitive. MOLT helps you standardize naming (lowercase vs quoted identifiers).
• Primary Keys SQL Server’s INT IDENTITY pattern causes write hotspots in distributed systems. Prefer:
• UUID
• BIGINT with unique_rowid()

This ensures inserts are evenly distributed across nodes.

2. Data Migration: Full Load vs CDC

Downtime is rarely acceptable in production systems.

Full Load (Cold Migration)

• Export SQL Server tables to CSV or Avro
• Store them in S3 or Azure Blob Storage
• Use CockroachDB’s IMPORT INTO for parallel ingestion

Best for: staging environments or short maintenance windows.

Continuous Replication (Zero-Downtime)

For live systems, use Change Data Capture (CDC):

• Qlik Replicate
• Striim

These tools:

• Capture ongoing SQL Server changes
• Stream them into CockroachDB
• Allow you to validate in parallel
• Enable a clean, low-risk cutover

3. Refining the .NET Application Layer

This is where most teams underestimate the work.

Audit Isolation Levels

• SQL Server defaults to Read Committed
• CockroachDB enforces Serializable

This is safer — but stricter.

Some transactions that used to pass may now retry. Your EF Core retry strategy (configured earlier) is essential.

The “Fat Transaction” Audit

Distributed databases penalize long-running transactions.

Red flags:

• Updating thousands of rows in one SaveChangesAsync()
• Holding transactions open across network calls

Fix:

• Batch writes (100–500 rows)
• Commit frequently
• Keep transactions short and deterministic

4. Testing the Chaos Scenarios (Mandatory)

Before production, test what SQL Server never prepared you for.

Chaos Test Example:

1. Deploy .NET services in US-East
2. Kill CockroachDB nodes in that region
3. Observe:

• EF Core retries
• Automatic rerouting to US-West
• No request loss
• No data corruption

If this test doesn’t pass, you’re not done.

✅ Migration Checklist for .NET Teams

• Replace INT IDENTITY with UUID or unique_rowid()
• Ensure every table has a Primary Key
• Configure Npgsql retry for error 40001
• Audit long-running transactions
• Simulate region failure before go-live

Final Takeaway

CockroachDB isn’t just a better database.

It’s a strategic insurance policy against the reality of modern cloud systems.

In 2026, resilience is not an optimization — it’s table stakes.

For .NET teams willing to embrace distributed-first thinking, CockroachDB offers:

• SQL without compromise
• EF Core compatibility
• Automatic failover
• Predictable correctness under chaos

Discussion Prompt

Are you currently planning — or actively avoiding — a migration away from SQL Server?

What’s the biggest technical or organizational blocker holding your team back?

SEO & Metadata

High-Intent Keywords CockroachDB EF Core migration,

SQL Server to CockroachDB,

distributed SQL .NET,

Npgsql retry strategy