DEV Community: Haik

Return or throw? Result pattern vs exceptions in ASP.NET Core

Haik — Wed, 11 Nov 2026 11:16:29 +0000

The order does not exist. Now what?

Every .NET API answers this question many times a day, and there are two camps. One throws a NotFoundException and lets something upstream turn it into a 404. The other returns the error as a value. Both work. Both have real costs.

This post lists the pros and cons of each, shows numbers, and ends with the rule I use.

TL;DR

Return the errors a caller can expect: not found, conflict, validation failed. They are 4xx.
Throw what should never happen: a bug, a dead database. It is a 500.
You need both, and both should produce the same error shape.

The exception way

public async Task<OrderDto> GetAsync(int id, CancellationToken ct)
{
    var order = await repo.FindAsync(id, ct)
        ?? throw new NotFoundException($"Order {id} does not exist.");

    return order.ToDto();
}

Somewhere else, an IExceptionHandler or a middleware catches NotFoundException and writes the 404.

What is good

It is built in. Every .NET developer knows it and every library already uses it.
The happy path stays clean. There are no checks after each call.
It cannot be ignored by accident. If nobody catches it, the request fails loudly.
You get a stack trace for free.
It crosses ten layers with no plumbing.

What is bad

The signature hides the failure. Task<OrderDto> says nothing about "not found". C# has no checked exceptions, so the caller learns the failure cases from the docs, or from production.
It is slow next to a plain return. .NET 9 made exceptions 2 to 4 times faster in micro-benchmarks, and they are still far from free. Numbers are below.
Expected events look like crashes. A user asks for a missing order, and many monitoring tools count one more exception.
The mapping lives far from the code. One handler has to know every exception type and its status code. Forget one and the client gets a 500.

The Result way

public async Task<Result<OrderDto>> GetAsync(int id, CancellationToken ct)
{
    var order = await repo.FindAsync(id, ct);
    if (order is null)
        return Error.NotFound($"Order {id} does not exist.");

    return order.ToDto();
}

The method returns the value or an error. The caller checks which one it got.

What is good

The signature tells the truth. Result<OrderDto> says "this can fail", and the caller has to look before it reads the value.
It is cheap. An error is a normal return value, with no stack unwinding.
Expected errors stay out of your exception tracking. A 404 is not an incident.
Mapping to HTTP is mechanical. The error already knows its type, and the type knows its status code.
Tests are simple. Call the method, assert on what came back.

What is bad

Plumbing. Every caller has to check and pass the error up. The code is below.
It spreads. Once a service returns a Result, its callers do too.
There is no stack trace. You know what failed, not where.
It can be dropped. C# does not force you to use a return value. Call a method that returns a Result, forget to check it, and the error is gone without a warning. An exception never lets you do that.
There is no standard type. .NET has no built-in Result, so you pick a library or write your own. C# 15 unions give you the "value or error" shape, but you still write the HTTP mapping yourself.
You still need exceptions. EF Core throws, HttpClient throws, your own bugs throw. A Result does not replace the exception handler. You run two systems.

This is the plumbing, repeated at every level:

var order = await orders.GetAsync(orderId, ct);
if (!order.IsSuccess)
    return order.Error;

return await billing.ChargeAsync(order.Value, ct);

What it costs

I measured a 404 from a service three async calls deep, on .NET 11 with BenchmarkDotNet. "Whole request" is a full GET /orders/{id} through an in-memory TestServer.

A 404 as	Alone	Whole request
Thrown exception, caught by `IExceptionHandler`	4,834 ns, 2,808 B	16.6 µs, 19.6 KB
Returned `Result<T>`	68 ns, 64 B	5.2 µs, 12.4 KB

Alone, the throw costs about 70 times more. Inside a whole request, about 3 times more. It is one laptop, so read the ratio and not the absolute numbers. The method and the raw output are in the repository.

Be honest about what this means. If your endpoint calls a database, 11 microseconds is noise. Speed alone is a weak reason to switch. It starts to matter when errors are common: a public API scanned by bots, a lookup endpoint that mostly answers 404. Bad requests are the ones anybody can send for free, so it helps when they are also the cheapest ones to answer.

The stronger reasons are the other ones: an honest signature, and quiet monitoring.

So which one?

Both. They answer different questions.

Return what the caller can expect and act on: not found, conflict, validation failed, forbidden. These are part of the contract of your API. They are 4xx responses.
Throw what should never happen: a bug, a null where none can be, a database that is down. Nobody upstream can fix it. It is a 500, and somebody should get an alert.

A quick test: should this wake someone up at night? If yes, it is an exception. If the client just did something clients do, it is a result.

This has one practical consequence. You need both pipelines, and both must produce the same error shape. The client should not be able to tell which one wrote the response. In ASP.NET Core that shape is ProblemDetails (RFC 9457).

Where ResultCrafter fits

Wiring those two pipelines into one shape is boring work, and I got tired of doing it in every project. So I wrote ResultCrafter, a small open-source library for .NET 10 and later.

HaikAsatryan / ResultCrafter

Result pattern for ASP.NET Core: errors become the right status and RFC 9457 ProblemDetails in one call. NativeAOT-safe.

Return errors. Don't throw them. ResultCrafter gives your ASP.NET Core services a Result<T> and turns it into the right HTTP response in one call. Errors leave as clean RFC 9457 ProblemDetails, the same shape every time.

The idea

Exceptions are for surprises. A missing order is not a surprise. It is Tuesday. So the service returns it:

public async Task<Result<OrderDto>> GetAsync(int id, CancellationToken ct)
{
    var order = await repo.FindAsync(id, ct);
    if (order is null)
        return Error.NotFound($"Order {id} does not exist.");

    return order.ToDto();
}

The endpoint maps it in one call:

app.MapGet("/orders/{id:int}", async (int id, OrderService orders, CancellationToken ct) =>
    (await orders.GetAsync(id,

…

View on GitHub

dotnet add package ResultCrafter.AspNetCore

builder.Services.AddResultCrafter();

var app = builder.Build();
app.UseResultCrafter();

app.MapGet("/orders/{id:int}", async (int id, OrderService orders, CancellationToken ct) =>
    (await orders.GetAsync(id, ct)).ToOkResult());

The client gets a 200 with the order, or this:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.5",
  "title": "not_found",
  "status": 404,
  "detail": "Order 42 does not exist.",
  "instance": "/orders/42",
  "traceId": "00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-00",
  "requestId": "0HN8K2MJ7F4QP:00000001"
}

What it does for you:

Returned errors get the right status: 400, 401, 403, 404, 409, 410, 422 and 429.
Unhandled exceptions become a clean 500 in the same shape, with full detail in Development and a plain message in Production.
It covers the "dropped result" weakness at the edge. Return a Result from an endpoint without mapping it and it fails loudly on the first run, instead of sending your error with a 200.
It logs 4xx at Warning and 5xx at Error.
It works with Minimal APIs and controllers, and it is NativeAOT-safe.

It is small on purpose: Map and Match, no Bind, no railway chains. If you want a full functional toolkit, or you are on an older .NET, ErrorOr, FluentResults and Ardalis.Result are good libraries. I keep an honest comparison table in the repository.

The package is ResultCrafter.AspNetCore on NuGet.

Your turn

Pick the rule first and the library second. Return what you expect. Throw what you do not.

Where do you draw the line in your APIs? Do you throw your 404s or return them? Tell me in the comments, especially if you disagree.

I'm a .NET Developer. I Benchmarked Java vs C# and I Didn't Like the Answer. Again.

Haik — Tue, 20 Oct 2026 05:37:58 +0000

In August I benchmarked Go against C# and did not enjoy the result. But I had a consolation prize ready:

Fine, Go is lean. But at least we beat Java.

I have written C# for years, and "modern .NET is faster than Java" is one of those facts you pick up without ever checking. Every talk and every "C# vs Java" video I have seen lands on the same side. I had honestly never heard anyone argue the opposite.

So I checked. I built the same invoicing API twice: once in Java 25 with Spring Boot and Hibernate, once in .NET 10 with Minimal API and EF Core. Same PostgreSQL, same Redis, same six CPU cores each. Then one 16-hour run and 44 million measured requests.

The short version:

Speed: a tie. Both stayed fast up to about 4,800 requests per second.
CPU: Java used half. .NET burned about twice the CPU time for every request.
Memory: .NET used a quarter. 176 MB against Java's 656 MB.
Money: Java was cheaper to run. A CPU core rents for 8 to 10 times the price of a gigabyte of RAM, even in the year RAM prices went crazy. Unless your services are small and sleepy. Then .NET wins.

I looked for the config mistake that explains it. I did not find one.

Why everybody "knows" .NET is faster

Mostly because of one table.

For over a decade, TechEmpower's Framework Benchmarks were the scoreboard everyone screenshotted. In the final round (Round 23, February 2025), the Fortunes test shows ASP.NET Core at about 610,000 requests per second and Spring at about 244,000 (the numbers people share). Two and a half times faster. Put that on a slide and the meeting is over.

The project shut down in March 2026, but screenshots are forever.

Here is the catch, which I went through in the last post: the rows at the top are hand-tuned entries with most of the framework ripped out. Nobody ships that code. It is a drag racer. It tells you nothing about what your family car burns on the way to work.

Last time, real code did not behave the way the scoreboard said it would. So I stopped trusting it for Java too, and measured.

The test

The app is called Ledgerline. It is a boring invoicing backend, on purpose. Look up an invoice. List a customer's invoices. Price a quote. Create an invoice with line items. PostgreSQL holds 1 million customers and 5 million invoices, and Redis caches the reads.

Both versions are written the way a normal team would write them.

	Java	C#
Runtime	Java 25 (LTS)	.NET 10 (LTS)
Web	Spring Boot 4, virtual threads	ASP.NET Core Minimal API, async/await
Database access	Hibernate 7	EF Core 10
Garbage collector	the default (G1)	the default (Server GC)
Given to each	6 CPU cores, 12 GB of RAM	6 CPU cores, 12 GB of RAM

The rule for both sides: if the project template gives it to you, it is in. If you would only add it to win a benchmark, it is out. I even removed four benchmark-flavoured tricks from my own .NET code before the run (a precompiled EF model, source-generated JSON, the slim app builder and a trimmed-down container image). Yes, I nerfed my own team.

Two .NET settings are not defaults, and both help .NET: DbContext pooling, which is common practice anyway, and automatic prepared statements in Npgsql, because Java's Postgres driver does that out of the box. Every other difference, on either side, is listed in the repo's FAIRNESS.md, including which side each difference hurts.

How the measuring works, in plain words:

A load generator sends requests at a fixed pace. It does not slow down when the service does, so a struggling service cannot hide.
I raise the pace step by step until the slowest 1% of requests take longer than 20 ms. (That "slowest 1%" number is called p99.) The traffic level where that happens is that stack's limit.
Then I run both at their limits, back to back, ten times. CPU and memory are read from the Linux kernel's own counters, not from what the runtimes say about themselves.

Only one service runs at a time, and each gets a few minutes of warm-up traffic before anything is recorded.

The results

Speed: a tie

Java's limit was 4,799 requests per second. .NET's was 4,833. That is a 0.7% difference. A draw.

And neither was out of breath. At that point Java was using about 1.1 of its 6 cores and .NET about 2.3. So the limit comes from something in the shared plumbing, like the database connection pool, and not from the language. I did not chase down exactly what.

Which means the real question is not "who is faster". It is "what does each one spend to be that fast".

CPU: Java did it with half

At its limit Java spent 0.233 milliseconds of CPU per request. .NET spent 0.481. That is 2.1 times more. In the back-to-back runs Java used 51.6% less CPU, and the result barely wobbled between runs (95% interval: 51.3% to 51.8%).

This is not a number picked at a flattering spot. From 1,500 requests per second all the way up, the gap stays between 2.0x and 2.2x. At light traffic it is wider: 3x at 500 requests per second.

Memory: .NET did it with a quarter

Now the other side. At its limit .NET held 176 MB of memory. Java held 656 MB, which is 3.7 times more. At light traffic the gap is even bigger: 59 MB against 461 MB, almost 8x.

Java was not squeezed, by the way. It was allowed about 3 GB of heap and its heap never passed 328 MB. This is simply how much elbow room a JVM likes.

Two things I was sure about, and was wrong about

"Hibernate must be hammering the database." I had a reason to think so. Hibernate cannot batch inserts on this schema, so creating one invoice costs Java about 11.5 trips to the database where EF Core needs 6. I measured PostgreSQL's CPU separately to catch exactly this. Result: 0.101 ms per request when serving Java, 0.115 ms when serving .NET. Postgres did not care.

"The JVM takes forever to warm up." Before every measurement, each service gets traffic until it settles: steady response times, steady garbage collection. The fastest that can possibly happen is 183 seconds.

Java settled in 183 seconds, 53 times out of 53. .NET usually needed 213 seconds, and 11 times out of 63 it ran into the 300-second time limit. The JVM, famous for showing up late, was early to every single meeting.

To be clear, this is not start-up time. I did not measure how fast each app boots, so I am claiming nothing about that.

So why does .NET need twice the CPU?

Honest answer: I do not know. I did not profile it. I can only tell you what it is not.

Not the database. See above.
Not garbage collection pauses. .NET does collect a lot, about 26 times per second at its limit, because it keeps its heap tiny. That is how it stays at 176 MB. But those pauses add up to under 2% of the time. Even if all six cores were busy during every pause, that is about 5% of .NET's CPU. Not half.
Not allocations. .NET actually allocated less per request: 68 KB against Java's 88 KB.

What is left is the request path itself: the web server, JSON, async, the database driver. Someone with a profiler and a free afternoon could probably name the top three. If that is you, the repo is open and I would love to know.

Same speed, different bill

So Java pays in RAM and .NET pays in CPU. Which one is cheaper depends on what RAM and CPU cost. And 2026 is a funny year to ask, because RAM prices went through the roof.

TrendForce, the people who track memory chip prices, forecast contract prices for ordinary DRAM up 55 to 60% in the first quarter, another 58 to 63% in the second, and 10 to 15% more this quarter. I fully expected that to flip my conclusion.

Then I opened the cloud price lists. These are the prices on October 20, 2026, US regions, pay-as-you-go:

Cloud	1 vCPU for an hour	1 GB of RAM for an hour	CPU costs
AWS Fargate	$0.0405	$0.0044	9x more
Azure Container Apps	$0.0864	$0.0108	8x more
Google Cloud Run	$0.0864	$0.0090	10x more

(AWS bills per GB, the other two per GiB, which is 7% bigger. It does not change the picture.)

Nothing moved. Azure's own price feed dates its rate to June 2022. So far the memory crunch has landed on GPUs (AWS raised its reserved GPU prices twice this year), not on the plain CPU and RAM a web API runs on. That can change, so check the date on this post.

Now price what each service actually used at its limit, with the AWS numbers:

	Java	.NET
CPU in use	1.12 cores	2.32 cores
Memory in use	0.66 GB	0.18 GB
CPU, per hour	$0.045	$0.094
RAM, per hour	$0.003	$0.001
Total, per hour	$0.048	$0.095

Run that for a month and it is roughly $35 against $69, for one small service.

Java's extra 480 MB of RAM costs about a fifth of a cent per hour. .NET's extra 1.2 cores cost about five cents. So RAM would have to get about 23 times more expensive before the two bills meet. It has been a wild year for RAM. Not that wild.

Two honest footnotes on the money.

Clouds sell RAM in a bundle with CPU. You do not pay for what you use, you pay for the size you pick. Fargate will not sell you 2 vCPU with less than 4 GB of RAM, or 4 vCPU with less than 8 GB. Both services fit inside that with lots of room to spare, so on a platform like that Java's extra memory costs nothing extra at all.

Small, sleepy services are a different story. When traffic is low, the CPU bill shrinks toward zero and the memory bill stays. At 500 requests per second .NET fit in 59 MB where Java needed 461 MB. By my math the two bills cross at around 100 requests per second per instance. That is below anything I measured, so treat it as a rough guess. But if you run a hundred little services that mostly sit idle on a shared cluster, you can pack almost eight .NET services into the memory of one Java service. That is real money too.

The memory gap is partly a choice each runtime makes for you. Java's garbage collector takes the room it is given. .NET's keeps the heap as small as it can and collects 26 times a second to do it. Neither is wrong. They just bet on different things being expensive, and on today's price list the expensive thing is CPU.

The fine print

One machine, one full run. A shorter rehearsal earlier the same day gave the same picture: about half the CPU for Java, 3.8x the memory.
One kind of app. A database-and-cache business backend. Heavy math, streaming or gRPC could land somewhere else.
Defaults only. I measured what the templates ship, not what a tuning expert could squeeze out of either side.
The 4,800 limit is a bit optimistic. When I re-ran both at exactly that rate, the slowest 1% averaged 27 to 29 ms, not 20, for both. So the true limit is a little lower for both. The cost comparison does not care: the CPU gap is 2x or more at every rate I measured.
Nine pairs, not ten. I planned ten back-to-back pairs. One .NET run never settled, so that pair was thrown out. My own rules said ten, so the report labels the verdict "directional".
Versions. Java 25.0.4 and .NET 10.0.11, measured on August 27 and 28, 2026. Both are still the current LTS lines. .NET 11 lands in November and Java 27 came out in September. I have measured neither.
No start-up times. Only how long each took to settle under traffic.
One thing I found after the run. This machine has a Linux setting that packs work onto the CPU's "best" cores, and it was almost certainly on. In a later test on the same machine it caused stalls. This run shows no sign of them, but I cannot fully rule it out. That, and how I will find what really caps both at 4,800, is in NEXT-ROUND.md.

All of it, plus the raw data and checksums, is in the run's own report.

So, Java or C#?

Here is the thing about this rivalry: it is a family argument. C# was born in 2000 as Microsoft's answer to Java, and Java's creator James Gosling called it "sort of Java with reliability, productivity and security deleted". A quarter of a century later the two have copied each other's homework so many times that they ended up with nearly the same feature list: records, pattern matching, cheap concurrency, a long-term release every two years, a library for everything, and jobs on every continent.

So pick like this:

Pick the one your team knows and can hire for. This beats everything below. A happy Java team will out-ship a grumpy C# team, and the other way around, by a lot more than 2x.
Then look at your bill. Big busy services where CPU is the cost: this test says Java, at about half the compute. Lots of small quiet services where memory is the cost: this test says .NET, at a quarter of the memory or less.
And fix your queries first. A missing index will cost you more than anything in this post.

Before this run I would have told you modern .NET is faster than Java and moved on. Now I would say they are the same speed, one of them is quietly cheaper to run, and it is not the one my career is built on.

That is twice in a row. I am still writing C# on Monday.

Do not take it from a scoreboard, and do not take it from me either. Measure your own service.

Comments I expect

"It's EF Core." The database did the same amount of work for both. And I tested EF Core against Dapper and raw ADO.NET in the last round: the ORM was not where the big cost was.

"Use Native AOT." Native AOT does not cover the reflection EF Core relies on, so it would be a different app.

"Give .NET a bigger heap." I did not test it. It would cost memory and probably save some CPU. But GC pauses were under 5% of .NET's CPU, so I would not expect it to close a 2x gap. (The small heap is .NET's default behaviour here. It is called DATAS.)

"Spring Boot is the slow Java. Try Quarkus." Mainstream against mainstream was the point. Leaner stacks exist on both sides.

"Can I run it myself?" Yes. Everything is in the repo: both services, the test runner and the raw results. A full run needs Linux and at least 15 CPU cores. A 20-minute smoke test runs on a laptop.

Round 1, Go vs C#: post. Round 2 repo with both services, the method, the fairness list and the raw data: github.com/HaikAsatryan/java-vs-dotnet-benchmark. Every measured number in this post comes from run full-20260827T174611-fedora, except the rehearsal line in the fine print. Cloud prices were checked on October 20, 2026.

I'm a .NET Developer. I Spent Two Months Benchmarking Go vs C# and I Didn't Like the Answer.

Haik — Thu, 20 Aug 2026 11:22:10 +0000

I write C#. I have written C# for years. I like EF Core, I like LINQ, and every time somebody told me Go was faster, I opened the same leaderboard everyone opens and pointed at the row where ASP.NET Core sits on top.

Then I stopped arguing and measured it.

I built the same invoicing API twice, once in Go and once in C#. Same database, same cache, same six CPU cores, same latency promise. Two months of evenings and weekends went into building the two services, the spec they both implement and the harness that measures them; the measuring itself was four days, 618 windows and 358 million requests. Every CPU and memory figure is read straight out of the Linux kernel's cgroup accounting, so neither runtime got to grade its own homework.

The answer was not the one I wanted, and it was not close. I'll get to the numbers. First I have to show you why the leaderboard everybody quotes points the other way, because until that makes sense my numbers just look like one guy on the internet disagreeing with TechEmpower.

Everything is open source, so you can check the work as you go: github.com/HaikAsatryan/go-vs-dotnet-benchmark.

Part 1: why the leaderboard says the opposite

Someone tells you Go is faster. They always do. Ask how much, or faster at what, and the conversation gets vague fast. So let's start with the numbers everybody links.

TechEmpower was the reference for a decade. Its Fortunes test is the one worth quoting, because it is the only popular one that touches a database, an ORM, sorting, templating and HTML escaping instead of just echoing a string back. Round 23, February 2025:

framework	language	Fortunes req/s
ASP.NET Core	C#	609,966
Fiber	Go	338,096
Actix	Rust	320,144
Spring	Java	243,639
Express	Node	78,136
Django	Python	32,651

Round 23 Fortunes, popular-framework slice, as tabulated by Tuan Anh Pham. The full leaderboard has a long tail of C++ and Rust exotica nobody ships either.

C# is not just ahead of Go there. It is 1.8x ahead, on the most database-shaped test in the suite, and it has looked roughly like this for years.

So it should be settled, right? C# is faster, has a richer ecosystem, better tooling, a nicer type system and a bigger hiring pool. Everyone picking Go for backend services is being sentimental.

Then why is Docker written in Go?

And Kubernetes. And Terraform, Prometheus, etcd, containerd, Grafana, InfluxDB, Traefik, Caddy, CockroachDB, Vault, Consul, Cilium.

That is not one team's taste. That is essentially the entire infrastructure layer of the modern internet, built by people who measure things for a living, choosing the language the leaderboard calls slower.

"It's history" only gets you so far. Docker started in 2013, when .NET did not run on Linux. Fine. But .NET Core landed in 2016 and has been genuinely cross-platform for a decade, and in those ten years the infrastructure world kept picking Go anyway.

And then there is the one that should really bother a C# person.

In 2025, Microsoft ported the TypeScript compiler to native code, chasing roughly a 10x speedup. They wrote it in Go. The lead architect of TypeScript is Anders Hejlsberg, the man who created C#, and Turbo Pascal and Delphi before that. If anybody alive had both the ability and the motive to make C# the answer, it was him. He is also, by any measure, one of the best language designers who has ever lived, which is exactly why his choice is worth more than my benchmark.

His stated reasoning: Go was "the lowest-level language available that still has garbage collection," giving "optimized native code for all platforms" and "great control over data layout." On C#, despite everything AOT has added, he noted it is "bytecode-first," is not universally available across platforms, "doesn't have a decade of hardening" in that mode, and "was not engineered that way."

The three reasons people give, and why none of them is on your bill

Push on "Go is faster" and you usually get some mix of three things:

It starts instantly. Milliseconds. No JIT warm-up.
It ships as one small static binary. No runtime to install, tiny container image.
It sits on almost no RAM when idle. Ten megabytes and a nap.

All three are true. Go wins all three, and it isn't close.

Now look at what they have in common: none of them is on your bill. A backend service starts once and then runs for three weeks. Startup time is a number you watch during a deploy and then never think about again. Image size is a one-time pull. Idle RAM is what your service uses in the state where it is doing nothing, which is not the state you are paying for.

What you actually pay for is CPU-seconds and gigabyte-hours while it is serving traffic, and how much traffic one box takes before your latency promise breaks. And on those two, the leaderboard says C# wins.

The catch: which row are you quoting?

TechEmpower's results page has a Classification filter: Platform, Micro, Fullstack. A Fullstack entry uses the framework the way you would, with the real router and the real ORM. A Platform entry is allowed to bypass all of that and write low-level code straight against the runtime.

.NET's headline entry, aspcore, is Platform class: no MVC, no ORM, raw database connectivity. It is beautiful code, and it is not an application. It shows how fast the runtime goes once you take the framework out of it.

Compare the Fullstack rows instead and the order flips. Dustin Moris Gorski ran exactly that comparison on Round 21: ASP.NET Core MVC with real templating managed about 184k req/s on Fortunes, while a Go entry did about 381k. (Different round, different hardware, so don't line those up against the table above. The ordering is the point.) Same benchmark, same test, opposite answer, depending entirely on which row you quote.

TechEmpower shut down in March 2026. Its announcement gives no reasons, so I won't invent any, but the widely shared community read was that those low-level tricks had turned it into "more a socket benchmark than actual real-life implementations used by end-users."

It measured what it measured, extremely well: the ceiling of a runtime when an expert strips the framework away. .NET's ceiling really is spectacular. It just is not the thing you deploy.

So I measured the thing you deploy.

Part 2: the benchmark I ran

What I built

Ledgerline is a small invoicing API. Create an invoice (a real multi-statement database transaction), fetch an invoice (cache-aside through Redis), list a customer's invoices, price a quote, and a PDF-stub endpoint.

I wrote the spec once, froze it before measuring anything, and implemented it twice the way a normal team would ship it:

Go: net/http, sqlc over pgx, go-redis.
C#: Minimal API on .NET 10, EF Core, Npgsql, StackExchange.Redis.

No hand-rolled routers. No pre-built byte arrays. No leaderboard tricks. Boring code on both sides, the kind that shows up in a pull request without anyone commenting on it.


Hardware	Ryzen 9 7950X, Fedora 43, tuned: CPU governor pinned, boost off, SMT siblings excluded
CPU budget	service under test 6 cores, PostgreSQL 3, load generator 3, Redis 1, each in its own cgroup and cpuset
Go side	Go 1.26.5, net/http, sqlc over pgx v5.10.0, go-redis 9.22
C# side	.NET 10, Minimal API, EF Core 10.0.11, Npgsql 10.0.3, StackExchange.Redis 3.1
Shared	PostgreSQL 18.4, Redis 8, 24-connection pools on both sides, verified warm at 24/24 in every cell
Load	vegeta 12.13, open loop, 120-second measured windows behind gated warm-ups
Working set	1,000,000 pre-generated requests drawn Zipf-hot from 5M seeded invoices. Measured Redis hit rate 0.807
The promise	mixed-workload p99 at or under 20 ms
Receipts	618 measured windows, 358,673,386 requests, four days

Three things make those numbers mean something. If you're newer to this, these are the parts most blog benchmarks get wrong:

1. Every CPU and memory figure comes from cgroup v2. That's the kernel's own accounting for the container, not something the process said about itself. A runtime cannot flatter itself here.

2. The load is open loop. A closed-loop generator waits for a response before sending the next request, so when your server slows down, the generator politely slows down too and hides the failure. An open-loop generator keeps firing at the offered rate regardless. That's how real traffic behaves, and it's the only way to see a service actually fall over.

3. The database gets its own cores, and it never broke. Before any measured run I laddered PostgreSQL on its own 3 cores to 3,715 req/s of create-only traffic, the heaviest thing in the mix, and it was still keeping up when the ladder ran out. It never broke during the runs either. Fair warning on this one: my pre-registered headroom check compared that against a demand figure I estimated before the ladder ran, and the runs ended up going faster than I planned for, so read the database as unfalsified rather than proven innocent. Both services faced the identical database, interleaved in time, so the comparison holds either way.

p99 means: sort every response time in the window, take the value 99% of them come in under. It's the slow-tail number. Averages hide pain; p99 doesn't.

Part 3: the results

Result 1: Go did the same work for a third of the CPU

Same rate, same work, same box:

Read the ratios left to right, because this is the most practically useful thing in the post. The ratio is not a number, it is a curve.

Go's per-request cost is a flat line: 7.4% coefficient of variation across 19 rungs spanning a 26x range of load. It costs what it costs.

C#'s cost falls by more than half as load rises, because tiered JIT, dynamic PGO and the runtime's fixed overheads amortise across more requests. That's why the gap is worst exactly where most services live. A .NET service cruising at 10% CPU is sitting at the expensive end of its own curve.

Across every rung of every configuration I ran, the range is 2.64x to 4.85x. If you want one number to plan with, use 3x, and expect worse than that if your traffic is modest.

Result 2: 5x less memory, with one honest caveat

The entire steady-state Go service, serving thousands of requests per second with a database and a cache client attached, fits in about 32 MB. That's a quip, not a claim, but it's a good one.

And now the caveat, because I would rather you hear it from me than from the comments:

If you size containers by the kernel's high-water mark over the container's whole life (which includes page cache and warm-up), the two land within 15% of each other. Go's advantage is in steady-state memory, which is what you feel when you pack services onto a node. It is not the number your orchestrator's memory limit has to be.

There's one more place Go looked bad, and you should know about it. In a configuration where I told both runtimes that memory was free (GOGC=off against .NET with dynamic heap adaptation disabled), Go ballooned to 6.6 GB while .NET held 212 MB. Go's small footprint is a default, not a law of nature. That configuration failed my warm-up gates by construction, so I file it as posture rather than measurement, but it is the one result in this whole run where Go lost badly.

Result 3: C# hits the wall first

Cost is the bill. Capacity is the cliff.

The C# service held the 20 ms promise up to 10,426 req/s. Past that, the tail came apart the way tails do: not gracefully.

Go did not break. Not there, not in any of the five configurations I ran. At the highest rate the run ever offered, 13,312 req/s, Go's warm windows averaged a 16.3 ms p99 while C# was at 103 ms and long past its wall.

offered rate	Go p99	C# p99	20 ms promise
11,093 req/s	15.2 ms	23.7 ms (worst window 39.3)	Go meets, C# misses
13,312 req/s	16.3 ms (worst 20.4)	103.1 ms*	Go meets, C# is past its wall

* C# at 13,312 is past its own wall, and all ten of its windows were thrown out by my pre-registered gates: six for an error rate up to 2.5% (the limit is 0.1%) and four for delivering as little as 81.5% of the offered load. Read it as posture, not a measurement. This is what the far side of a wall looks like.

So Go holds the promise to at least 1.28x the rate C# does. I can't tell you the real multiple, because I never found Go's wall. Four days of trying, and the honest answer is "further up than my load generator went."

"It's EF Core's fault." No, it isn't.

Before anyone says it: yes, I checked. Four data layers, each a full multi-hour run on the identical workload.

The three at the top are the same number. EF Core, Dapper and hand-written ADO.NET land within 2.5% of each other, and EF costs about 20% more CPU per request than raw ADO at the same rate. You cannot rewrite your way out of the Go gap by dropping the ORM.

The outlier at the bottom is EF Core on Npgsql's defaults. The fix is one connection-string setting, Max Auto Prepare, which pgx has on and Npgsql does not: turn it on and EF Core goes from 1,468 to 10,426 req/s. That is 7x.

But look at what the other two rows are telling you. Dapper and raw ADO.NET ran with that same setting at its default of off, and they still reached 10,177 and 10,334. So this is not an Npgsql default that hurts every .NET data layer. It is specific to how EF Core issues its parameterised queries when they aren't prepared: hand-written SQL on the same driver, same default, doesn't care. Everything else in this post uses the fixed configuration, so the Go-vs-C# comparison is not quietly carrying that difference.

Hold on to that number. It comes back in a minute.

What I am not claiming

A benchmark that only tells you the good parts is marketing. Here's what this run does not support:

No Go knee. Go never crossed 20 ms in any ladder I ran, so its wall is unmeasured. Every Go capacity number here is a floor.
Not a single ratio. Cost per request is a curve on both sides. Every ratio here is stamped with the rate it was measured at.
These knees are not precision instruments. The crossing brackets carry as few as one or two measurement-grade repetitions against a pre-registered minimum of ten. The third digit of any knee is decoration. The ordering is not.
Warm-window thinness is this run's biggest data-quality cost. My warm-up gates (GC cadence steady, tail flat, pools warm) flagged 59.5% of all 618 windows, and they hit Go harder than C# (67% vs 52%) because Go's per-second p99 wanders more at high rates. Some Go roll-ups rest on one or two fully-warm windows. The counts ride along with every table in the repo.
No statistical significance on the paired latency deltas. Only the low-rate configuration produced enough warm pairs to run the test; n was 2 and 3, and the intervals span zero. Direction and effect size only.
TechEmpower is not wrong on its own terms. It measures what it measures, extremely well. I'm claiming it doesn't measure your service, and that people quote it as though it does.
Not captured: per-query PostgreSQL CPU attribution, GC pause histograms, and anything off this one box, one workload, one topology.
And both of these are genuinely fast. At 9,244 req/s, a rate most services will never see, Go's p99 was 2.4 ms and C#'s was 4.1 ms. The gap here is a bill, not a broken service.

Hygiene, since a benchmark should show its receipts: 618 measured windows, 358,673,386 requests, seven HTTP 500s in total, zero CPU-throttled windows, zero OOM kills, achieved rate equal to offered rate in every window I kept, and a cross-implementation equivalence suite passing 19 of 19 before the run started. There were also 906,235 connection-level failures with no HTTP response at all, 0.25% of the total, essentially all of them at rates past a service's wall. Those probes are excluded from every fit by a rule I wrote down before the run.

So what does this actually mean?

Let me say the uncomfortable part plainly, because I'm the one who has to live with it.

On the code people actually ship, Go beat C# on every performance axis I measured. Not narrowly. Not in a lab. Not with tricks:

~3x less CPU per request at the same load, and up to 4.85x at low load.
3x to 5x less steady-state memory while serving.
Lower p99 at every confirm-stage operating point in the run. (On the exploratory ladder, where some rungs rest on a single window, Go's tail wanders and a few rungs land above C#. That noise is visible in the latency chart and it is why the analysis fits a monotone curve instead of trusting one point.)
More traffic before the latency promise broke, with no measured ceiling.

That is the answer to "why is Docker written in Go?" It isn't that Go's runtime wins in a lab; .NET's ceiling is higher than Go's. It's that Go's floor (the cost of ordinary code doing ordinary work) is about three times cheaper, its cost is flat and predictable at every load, and it doesn't have to be busy before it stops being expensive. That's the number that lands on an invoice every month, and it is what the infrastructure world has been telling you for a decade by choosing Go.

And the next time someone links you TechEmpower: that benchmark measured a runtime with the framework surgically removed by an expert. Nobody ships that code. It never measured what you deploy, and as of March 2026 it isn't running at all. Ask them which row they're quoting: Platform, or Fullstack?

I'd rather have found the opposite. But the point of measuring is that you don't get to choose.

Now the part that actually matters

Everything above is about speed and cost. That's one axis. On most projects it is not the axis that decides anything, and I'd be doing you a disservice if I let a benchmark post end at "use Go."

So here's the guide I'd actually give a junior engineer asking "which language should we use?"

The one-sentence version: for a new product you can pick almost anything, including Python, which is around an order of magnitude slower than either language in this post and still runs Instagram. Ship first, measure later. The longer version is below.

1. The most important input is your team, not the language

The first question is not "which language is fast." It's "which language can my team write well, and can I hire more of those people where I am?"

A team fluent in C# will ship a better, safer, faster C# system than an unfamiliar Go one. Language performance is a constant factor. Team fluency is a multiplier on everything else: design quality, review quality, how fast bugs get caught, how long onboarding takes, whether you can replace someone who leaves.

If you cannot hire it, it doesn't matter how fast it benchmarks.

2. Architecture beats language by an order of magnitude. I measured that by accident.

Look at that data-layer chart again. One Npgsql connection-string setting moved C# from 1,468 to 10,426 req/s. That's 7x, from one line of configuration, and it's more than twice the entire Go-vs-C# gap.

Now think about the things that are far worse than a missing config flag:

an N+1 query in a hot path
a missing index
a chatty service boundary that turns one request into twelve
no cache where a cache obviously belongs
a synchronous call where a queue belonged

Each of those routinely costs 10x to 100x. Go with any of them loses to C# without them, and it isn't close.

You cannot out-language a bad design. You can very easily out-design a slow language.

3. You don't pick a language once. You pick one per service.

Go and C# in the same company is completely normal and not a smell. Different services have different shapes. Treating "our language" as a company-wide identity is how you end up writing a Kubernetes operator in C# and a claims-adjudication engine in Go, both for no reason.

4. Use each language for what it was built for

Go was designed at Google for infrastructure: fast builds, one static binary, cheap concurrency, and a deliberately small language that a large team reads consistently. That minimalism is a feature when the domain is thin and a tax when it's thick. Reach for Go when the surface area is small and the volume is high: proxies, gateways, agents, CLIs, schedulers, cloud-native tooling, high-throughput plumbing, anything that ships as one binary and gets deployed 500 times.

C# / .NET was built for applications with deep business rules. When the hard part isn't throughput but modelling 200 rules that change every quarter, a rich type system, LINQ, a real ORM and a mature ecosystem for the boring things (background jobs, validation, mapping, reporting, integrations) are worth far more than 3x CPU. Billing, ERP, insurance, healthcare, e-commerce with real pricing and promotions: that's where I'd still pick C# knowing everything in this post. Writing that domain in Go is possible, and it is a lot more typing.

"But Rust is faster than Go. Why isn't Docker in Rust?" Because speed is not the only axis, which is the entire point of this post. Rust beats Go on CPU and memory and has no GC pauses at all, and it charges you for that: an ownership model your whole team has to learn, slower builds, a smaller hiring pool, and real friction with the cyclic, graph-shaped data structures that compilers and orchestrators are made of. Go is the point on that curve where you get most of the systems-language win for a fraction of the cognitive cost. The TypeScript team wrote down exactly this trade: a from-scratch Rust rewrite would have been a multi-year job producing something incompatible, while Go let them port the existing compiler largely mechanically. Plenty of infrastructure is written in Rust today, and when you genuinely need the last increment of performance and can pay for it, that is the right call. Most teams do not, and cannot.

The honest caveat, because absolutes are how you get torn apart in the comments: all of this is a centre of gravity, not a law. Monzo runs a bank on roughly 1,600 Go microservices. That's an argument about how you slice a system, not about whether Go can hold money. Their complexity lives in the topology; the counter-case is one thick domain model in one service.

5. Do the arithmetic before you care about 3x

Paying 3x means a bill that could be \$100 is \$300 instead. So:

Compute bill of \$300/month on C#? Moving to Go saves you around \$200/month. Nobody should re-architect for that.
Compute bill of \$200,000/month on C#? Moving to Go saves you around \$130,000/month. That is somebody's full-time job, and then some.

Work out which one you are. Most people argue like the second and live like the first.

6. When the bill does hit, you don't rewrite everything

You profile, find the two or three services that dominate the invoice, and rewrite those. That's a sprint, not a year, and by then you'll have the revenue and the traffic data to do it properly.

"We'll rewrite the hot paths later" is not technical debt. It's the correct plan.

Quick answers to the comments I'm going to get

"But TechEmpower says C# is faster."
It measured a runtime with the framework stripped out by an expert. Nobody ships that. Ask which row is being quoted: Platform, or Fullstack?

"What about Native AOT? Doesn't that close the gap?"
I didn't test it, so treat this as reasoning and not data. AOT buys you the three things I argued aren't on your bill: instant startup, a small self-contained binary, no JIT warm-up. Those are real wins, and they are exactly the Go advantages that never show up on a long-running service's invoice. What AOT does not obviously improve is steady-state CPU per request, and it gives up the JIT's dynamic PGO, which is part of why the C# curve in my chart gets cheaper as load rises. It could go either way and I'd want to measure before claiming a direction.

The reason I spent none of those four days on it: AOT still doesn't cover a large part of the .NET ecosystem. Anything that leans on runtime reflection or dynamic code generation either needs rework or isn't supported, and that describes a lot of what makes .NET pleasant to write. Hejlsberg made the same point when explaining the TypeScript port: C# is still "bytecode-first," isn't available everywhere, and "doesn't have a decade of hardening" in AOT mode. So I genuinely don't know how much real-world adoption AOT has for services shaped like this one. If you've run this comparison, I want to see it.

"So we should migrate to Go?"
Only if your compute bill is genuinely large, your domain is genuinely thin, and your team can write good Go. Two out of three is a no.

"Isn't this just EF Core being slow?"
No. Dapper and hand-written ADO.NET land within 2.5% of EF Core's number.

"Does this mean C# is bad?"
No. Both services were fast. At 9,244 req/s, Go's p99 was 2.4 ms and C#'s was 4.1 ms. This is a bill, not a broken service. I'm still writing C# on Monday.

"Your Go/C# code is unidiomatic."
Maybe! The spec, both implementations, the runner and every raw artifact are in the repo, and there's an issue template for exactly this. Send a PR, I'll re-run it.

Go and C# are not rivals. They're tools with different centres of gravity, and plenty of good companies run both. This benchmark says Go's floor is about three times cheaper than C#'s. That's a true and useful fact, and it is nowhere near the most important input to your next architecture decision.

Just don't take it from a leaderboard. Measure your own service, at your own rate, and read the accounting from the kernel rather than from a scoreboard.

Run 20260814T051533-fedora. Every number here was recomputed from the per-probe raw artifacts (vegeta summaries, cgroup deltas, warm-up gate records) rather than quoted from the pipeline's own report, and the two agree. The spec, both service implementations, the analysis pipeline, the figure-generation script and the full artifact tree are in the repo. TechEmpower figures are Round 23 (February 2025). If you find a hole, open an issue and I'll fix the post.

PostgreSQL Write Performance: What the Benchmarks Won't Tell You

Haik — Sun, 12 Apr 2026 18:24:28 +0000

I've spent years building financial systems on PostgreSQL. Payment processing, account management, transaction engines. The kind of systems where every write matters and you can't cut corners.

A while ago, I kept running into the same story online: "Boost your PostgreSQL to 100,000 inserts per second." "Python + Postgres: 1 million requests per second." The numbers were everywhere. Conferences, blog posts, YouTube videos. So when one of our products, a well-architected .NET application with a properly configured PostgreSQL instance, barely hit 1,000 writes per second on hot paths, I thought we did something wrong.

We didn't.

I spent weeks digging into this. Reviewing our code, our PostgreSQL configuration, our infrastructure. Everything was solid. The architecture was clean. The queries were optimized. The connection pooling was in place. And then I started actually reading those benchmarks carefully. That's when I realized: most of them are, to put it politely, not representative of real-world workloads.

This blog is what I found.

TL;DR: On a 16-core Ryzen 9 with a top-tier NVMe and 62 GB RAM, a single PostgreSQL 18 node tops out at ~1,875 realistic transactional writes per second with full durability. In production with standard SSDs and more complex schemas, expect less. That's a long way from the 100,000 inserts/sec that synthetic benchmarks advertise. Full benchmark results and methodology below.

Why Only Writes?

Let me be upfront about the scope. This post is only about write performance. Not reads. Not bulk inserts. Single-row transactional writes: the kind that happen when a real user hits a real API endpoint and expects a real result.

Why ignore reads? Because read performance on PostgreSQL is, relatively speaking, a solved problem. Not trivial, but well-documented and dramatically easier to scale. The toolkit is rich and the path is clear:

Indexing strategies are mature. B-tree, GIN, GiST, partial indexes, covering indexes. There are dozens of excellent guides on this.
Read replicas scale horizontally with minimal effort. You can set up a CQRS pattern with N replicas, and PostgreSQL handles replication natively.
Partitioning works well and keeps large tables manageable.
PostgreSQL 18 introduced asynchronous I/O for read operations, delivering significant performance improvements (up to 2-3x on cloud storage with higher latency, and measurable gains even on local SSDs). Worth noting: this async I/O applies only to read operations. Writes, including WAL flushing, remain synchronous. (PostgreSQL 18 Release Notes)
PgBouncer and connection pooling eliminate connection overhead.
Shared buffers and OS page cache can serve most read workloads entirely from RAM.

To put this in perspective: OpenAI runs a single-primary PostgreSQL deployment with nearly 50 read replicas, serving millions of queries per second for 800 million ChatGPT users. Their read scaling works. Their bottleneck? Writes. They directed new write-heavy workloads to Azure Cosmos DB because PostgreSQL's single-node write architecture has real limits. (OpenAI: Scaling PostgreSQL. Side note: this post is well worth reading in full. It's one of the clearest and most insightful pieces on real-world database scaling I've come across.)

The point is: if you need to scale reads, you have options. Lots of them. If you need to scale writes, you're entering a fundamentally different territory.

Why Not Bulk Writes?

Bulk inserts are a different game. PostgreSQL's COPY command, combined with tools like Kafka for batching, can push hundreds of thousands or even millions of rows per second. Companies do this all the time for analytics pipelines, event ingestion, and log processing. There are plenty of good resources on bulk write optimization.

But that's not what this post is about.

Think about what happens when a customer taps "Pay" on their phone. That's a single API call. A single database transaction. It reads the account balance, checks constraints, inserts a transaction record, updates the balance, and commits. There's locking involved. There are indexes to maintain. There's a WAL (Write-Ahead Log) entry that must be flushed to disk before the commit is acknowledged.

You can't batch this. You can't tell the customer "hold on, we'll process your payment in 200 milliseconds when we have 500 other payments ready to go."

This pattern applies to every system where transactional integrity matters on a per-request basis: payment processors, banking platforms, healthcare record systems, e-commerce order processing, booking systems. Any application where a single user expects a single, atomic result from a single action.

Why Most PostgreSQL Write Benchmarks Are Misleading

If you've searched for "PostgreSQL write performance" or "PostgreSQL inserts per second," you've seen impressive numbers. 50,000 inserts per second. 100,000. Even higher.

Here's what those benchmarks typically do that your production system does not:

No indexes. The test table has a primary key and nothing else. In production, your orders table has indexes on customer_id, created_at, status, maybe a composite index or two, possibly a GIN index on a JSONB column. Every index you add is a separate B-tree that PostgreSQL must update on every single write. A table with 8 indexes requires nine separate write operations per insert (one for the heap row and one for each index entry), along with corresponding WAL records for each. The overhead scales linearly with index count and adds up fast.

fsync turned off. PostgreSQL's fsync setting controls whether the WAL is actually flushed to stable storage. With fsync=off, PostgreSQL never asks the OS to flush writes to disk. It's dramatically faster, and catastrophically dangerous. If the server crashes, you don't just lose recent data. The database can end up in an unrecoverable, corrupted state because partially-written pages go undetected. Every serious deployment runs with fsync=on. No exceptions. (PostgreSQL WAL Configuration)

synchronous_commit turned off. This one is more nuanced, and often conflated with fsync=off, but they're fundamentally different settings with fundamentally different risk profiles. With synchronous_commit=off, PostgreSQL still writes WAL records, but doesn't wait for the disk flush before acknowledging the commit. If the server crashes, you might lose the last few hundred milliseconds of committed transactions, but the database recovers to a consistent state via WAL replay. PostgreSQL's own documentation explicitly states this "does not create any risk of database inconsistency." Using synchronous_commit=off per-transaction for non-critical writes (logging, metrics, notifications) is a legitimate, documented production pattern. But when benchmarks use it globally without disclosure and then claim "50,000 writes per second", that's a number your production system with synchronous_commit=on will never match, and it's misleading to present it without context. Our benchmark tests both settings to show the actual gap.

Unlogged tables. PostgreSQL supports tables that skip WAL entirely. Faster? Absolutely. Production-ready for financial data? Absolutely not.

No real business logic. Production writes aren't just INSERT statements. They involve SELECT ... FOR UPDATE locks, constraint checks, foreign key validations, and often multiple statements within a single transaction. The benchmark inserts a row into an empty table and calls it done.

No concurrency contention. Real systems have hundreds of connections competing for the same rows, the same indexes, and the same WAL buffer. Benchmarks typically measure throughput under ideal conditions with no lock contention.

No retries, no error handling. In production, serialization failures happen. Deadlocks happen. Your application retries, which means the effective throughput is lower than the raw insert rate.

"Just use a message queue." This is the most common response when someone brings up write performance concerns. RabbitMQ, Kafka, SQS, pick your flavor. The idea is simple: accept the request, drop it onto a queue, return 202 Accepted, and let a background worker handle the heavy write later.

And to be clear: this is a great pattern. We use it. You can make the initial synchronous write much cheaper (a lightweight "pending" record with fewer indexes, or an append to an event log) and defer the expensive multi-table transactional work to a background consumer. For periodic traffic spikes, it's brilliant: even if the consumer falls behind, it catches up during quieter periods, and retries handle transient failures gracefully.

But it does not raise the database's sustained write throughput.

Here's why. Even with the cheapest possible initial write, the background worker still writes back to the same PostgreSQL instance: status updates, ledger entries, audit logs. You haven't removed writes from the database; you've spread them across time. Instead of one transaction doing everything, you now have the initial write, the queue acknowledgment (if durable), and one or more background completion writes. The total write count often goes up, not down.

For spikes, that's fine. The queue absorbs the burst and the database catches up. For sustained load at or near the ceiling, there's no catching up. The writes per second flowing into PostgreSQL are the writes per second flowing into PostgreSQL, whether they arrive from an API handler or a queue consumer. Async processing is an excellent architectural pattern for latency and resilience, but the write ceiling is still the write ceiling. The bottleneck just moves to a less visible place.

This isn't a minor difference. The gap between a synthetic benchmark and real-world write performance can easily be 10x or more.

Putting "Writes Per Second" in Context

Before we look at actual numbers, let's calibrate what "writes per second" means in real business terms.

1,000 sustained writes per second sounds small if you're used to thinking in terms of HTTP requests per second. But consider what it means:

1,000 writes/sec = 86.4 million writes per day
500 writes/sec = 43.2 million writes per day
100 writes/sec = 8.6 million writes per day

Stripe, one of the largest payment processors in the world, processes billions of API requests, but their actual payment transaction rate is a fraction of that. Most mid-size fintech companies never sustain more than a few hundred transactional writes per second.

Let me bring this closer to earth. I work in Armenia, a country of about 3 million people. The largest banks here sustain around 3 transactional inserts per second on their core tables on average. During peak hours, they might spike to around 100 inserts per second for brief periods. The entire national banking system doesn't come close to 500 sustained writes per second.

I once encountered a fintech here that was reporting roughly 1,000 inserts per second on a hot path. Impressive, until I looked at their architecture. They were running fast inserts in a loop within their application layer, not genuine one-user-one-request transactions. The system design was wrong. Once you filter out that kind of architectural mistake and look only at genuine single-request transactional writes, the numbers are dramatically lower than what people imagine.

When someone tells you their PostgreSQL setup handles "only" 1,000 genuine transactional writes per second, they're describing a system that could serve the transactional needs of a small country. The companies that genuinely need 10,000+ transactional writes per second on a single PostgreSQL instance are rare. And if you're at that scale, you're almost certainly a large enough operation that sharding is already on your roadmap, and you have the engineering team to handle it.

The Benchmark

Here's where I stop talking and show data.

I built a public benchmark designed to simulate real-world write patterns, not synthetic ones. You can find it here:

Repository: github.com/HaikAsatryan/pg-bench-real

Hardware

Component	Specification
CPU	AMD Ryzen 9 7950X, 16 cores / 32 threads @ 4.5 GHz
RAM	62 GB DDR5
Storage	WD_BLACK SN850X 2 TB NVMe (PCIe 4.0, ~7,300 MB/s seq read, ~6,600 MB/s seq write)
OS	Fedora 43 (kernel 6.19)
PostgreSQL	18.3

This is a strong machine, better than most production database servers. Keep that in mind: these numbers are likely optimistic compared to your production environment, which probably runs on cloud VMs with standard SSDs, shared resources, and network-attached storage.

PostgreSQL Configuration

Auto-tuned from hardware, production-safe settings:

Setting	Value
`fsync`	`on` (always, non-negotiable)
`synchronous_commit`	`on` (server default; benchmark also tests `off` per-transaction)
`shared_buffers`	`15 GB` (25% of RAM)
`effective_cache_size`	`46 GB` (75% of RAM)
`work_mem`	`64 MB`
`wal_buffers`	`64 MB`
`max_wal_size`	`4 GB`
`max_connections`	`300`
`effective_io_concurrency`	`200` (NVMe)
`random_page_cost`	`1.1`
`huge_pages`	`try`
`checkpoint_completion_target`	`0.9`

What We Tested

Two transaction shapes that model real enterprise write patterns:

Standard OLTP Write ("Record a new transaction"):

BEGIN
SELECT balance, status FROM wallets WHERE account_id = ?    -- account check
SELECT count(*) FROM transactions WHERE wallet = ? AND ...  -- rate/fraud check
INSERT INTO transactions (12 columns, incl. jsonb) VALUES (...)  -- the write
INSERT INTO audit_log (...) VALUES (...)                    -- compliance trail
COMMIT

4 statements per transaction. 2 reads + 2 writes across 2 tables. This is what a typical API endpoint does when recording a payment, order, or event. Not every API write includes a fraud-check scan, but most production transactions involve at least one read before writing. We included it because skipping all reads is exactly the shortcut that makes synthetic benchmarks unrealistic.

Banking Transfer ("Move money between two accounts"):

BEGIN
SELECT balance FROM wallets WHERE account_id = ? FOR UPDATE  -- lock source
SELECT balance FROM wallets WHERE account_id = ? FOR UPDATE  -- lock destination
UPDATE wallets SET balance = balance - ? WHERE account_id = ? -- debit
UPDATE wallets SET balance = balance + ? WHERE account_id = ? -- credit
INSERT INTO transactions (12 columns, incl. jsonb) VALUES (...)   -- record
INSERT INTO audit_log (...) VALUES (...)                     -- compliance
COMMIT

6 statements per transaction. 2 row locks held simultaneously across 5 statements. Canonical deadlock-avoidance ordering (always lock lower ID first). This is what creates real contention under load.

Schema: 12-column transactions table (including a jsonb metadata column) with timestamptz, numeric(18,2), varchar, and text fields. 5 B-tree indexes. Monthly range partitioning by created_at. 10,000-row wallets table. audit_log table with 2 indexes. 50 million rows pre-filled to push indexes beyond shared_buffers into the I/O-bound regime.

Access pattern: Zipfian distribution (alpha=1.0), where the top 1-2% of wallets absorb ~20% of traffic. This is what creates real contention. Uniform random access hides the single-node bottleneck we're trying to measure.

Timeouts: statement_timeout=5s, lock_timeout=1s, idle_in_transaction_session_timeout=10s. Production-realistic limits. A transaction that can't finish under these is counted as a rejection.

Connection pool: 50 connections (matching typical AddDbContextPool / HikariCP / psycopg-pool sizes).

Durability: Tested with both synchronous_commit=on (full durability, production default) and synchronous_commit=off (no fsync wait) to show the exact performance gap that benchmarks hide when they don't disclose this setting.

Driver: Open-loop with Poisson arrivals. The driver produces requests at a fixed target rate regardless of how fast the DB drains them. When the DB can't keep up, requests queue and eventually time out. This is exactly what happens in production when your API gets more traffic than your database can handle. An adaptive binary search finds the rate where failures start.

Results

Each probe ran for 7 minutes (spanning a full PostgreSQL checkpoint cycle) with 30 seconds of warmup discarded. The adaptive binary search converged to +/-6-9% brackets in 7 probes per sweep.

Standard OLTP Write (synchronous_commit = on)

Ceiling: ~1,875 rps (knee bracket: 1,875-2,046 rps)

At the ceiling, the system sustained 1,875 committed transactions per second with zero errors and a P99 latency of 58 ms. Push it to 2,046 rps and errors jumped to 9%, all from pool wait timeouts. The database didn't crash or deadlock; it simply couldn't drain its connection pool fast enough.

At the healthy ceiling: avg latency 9.2 ms, P50 3.1 ms, P99 58 ms. Over the 7-minute measurement window, 787,531 transactions committed successfully.

Banking Transfer (synchronous_commit = on)

Ceiling: ~2,390 rps (knee bracket: 2,390-2,562 rps)

The banking transfer, despite holding two row locks per transaction, achieved a higher ceiling than the standard OLTP write. Why? The standard OLTP write includes a SELECT count(*) fraud-check query on the 50M-row transactions table, an index scan that becomes expensive at scale. The banking transfer's reads hit only the 10,000-row wallets table, which fits entirely in shared buffers.

At the healthy ceiling: avg latency 8.8 ms, P50 2.6 ms, P99 144 ms. Zero deadlocks, zero lock timeouts. The canonical lock ordering (always lock lower account ID first) worked exactly as designed.

The synchronous_commit Gap

We tested both synchronous_commit=on and off to measure the gap that benchmarks quietly exploit:

Workload	sync_commit=on	sync_commit=off	Improvement
Standard OLTP Write	~1,875 rps	~1,875 rps	~0%
Banking Transfer	~2,390 rps	~2,734 rps	~15%

The result surprised me. For the standard OLTP write, skipping the durability flush made no measurable difference to the ceiling. The bottleneck wasn't WAL flush latency; it was the read queries and index maintenance within the transaction. When your transaction includes a range scan on a 50M-row table, shaving 0.5 ms off the commit doesn't move the needle.

For the banking transfer, synchronous_commit=off gave a 15% boost. Meaningful, but far from the 5-10x numbers that synthetic benchmarks imply. And remember: you're trading data durability for that 15%.

The latency at sub-ceiling rates tells a clearer story. At 500 rps (well below saturation), banking transfers dropped from 1.7 ms average (sync=on) to 0.8 ms (sync=off), a 2x latency improvement. But the ceiling barely moved. Faster commits let you do each transaction quicker, but the database still hits the same I/O wall.

How It Breaks

This chart tells the whole story. The line follows the diagonal (achieved = target) until the ceiling, then flatlines. Push harder and the database doesn't crash, doesn't deadlock, doesn't corrupt anything. It simply can't drain its connection pool fast enough. Your requests time out waiting for a connection, and your API starts returning 503s.

Every single failure at the knee was a pool wait timeout. Not a single deadlock. Not a single statement timeout. PostgreSQL is well-behaved at its limits: it just has a finite throughput.

Key Findings

The realistic write ceiling on strong hardware is ~2,000 rps. On a Ryzen 9 7950X with a top-tier NVMe drive and 62 GB of RAM (hardware better than most production database servers), the ceiling for a standard multi-statement OLTP write with 5 indexes, production timeouts, and full durability is approximately 1,875 writes per second. That's a long way from the 100,000 inserts/sec that synthetic benchmarks advertise.
Row contention doesn't kill you; large table scans do. The banking transfer (with two row locks held simultaneously) was actually faster than the standard OLTP write. The bottleneck was the fraud-check query scanning a 50M-row table, not the lock contention on 10,000 wallets.
synchronous_commit=off gives at most 15%, not 10x. Benchmarks that quietly use synchronous_commit=off suggest massive performance gains. In reality, with a realistic workload, the improvement is modest. The WAL flush is only one component of the total transaction cost.
The failure mode is clean. PostgreSQL doesn't crash, corrupt data, or spiral into deadlocks at the ceiling. It cleanly saturates the connection pool. Requests that can't get a connection within 1 second are rejected. This is a well-behaved system hitting a well-defined limit.
1,875 writes/sec = 162 million writes per day. This is enough to serve the transactional needs of a mid-size country's banking system. Most applications will never come close to this limit.

The WAL Bottleneck: Why Writes Are Fundamentally Hard

If you're wondering why write performance has a hard ceiling that read performance doesn't, the answer comes down to one thing: the Write-Ahead Log.

Every write in PostgreSQL (every INSERT, UPDATE, and DELETE) must first be recorded in the WAL before it can be acknowledged. With synchronous_commit=on, every transaction commit requires its WAL records to be physically flushed to disk.

WAL insertion itself has been concurrent since PostgreSQL 9.4: multiple backends can reserve LSNs and copy WAL records into shared buffers in parallel. But WAL flushing, the actual fsync() to disk, is serialized. That disk flush is the hard ceiling.

Read replicas don't help here. Partitioning doesn't help. More RAM doesn't help. The WAL flush is a serialized disk I/O bottleneck by design. It's what guarantees your data is safe, and it's what limits how fast you can write.

This is why horizontal write scaling (sharding) is fundamentally different from horizontal read scaling (replicas). Replicas are cheap: stream the WAL, apply it, serve reads. Sharding is expensive: split your data, split your application logic, handle distributed transactions, deal with cross-shard queries. Your code gets bigger, your architecture gets more complex, and your failure modes multiply.

Tools like Citus (now part of Azure) can help significantly. It extends PostgreSQL with distributed tables and handles a lot of the routing and query rewriting for you. But "significantly helps" is not the same as "makes it trivial." You still need to choose a distribution key, redesign queries that cross shard boundaries, handle distributed transactions carefully, and test thoroughly. I haven't personally needed to shard yet, so I can't speak from firsthand experience, but the engineers I've talked to who have describe it as a serious undertaking even with good tooling.

For a deeper dive into WAL mechanics: PostgreSQL Documentation: Write-Ahead Logging

When Should You Start Worrying?

The benchmark ceiling of ~1,875 rps was measured on strong hardware: a 16-core desktop CPU, a top-tier NVMe, and 62 GB of RAM. Your production environment is almost certainly worse.

In my own experience, a well-architected .NET application running on production hardware with standard SSDs (not NVMe), a more complex schema (more columns, more indexes), and real network latency topped out at around ~1,100 writes per second. That's 40% lower than the benchmark, and our setup was well-optimized.

Here's the framework I'd recommend:

At 500+ sustained transactional writes per second, start planning. Not panicking, planning. You have time, but the wall is real, and architectural changes (sharding, CQRS, write offloading) take months to design and years to fully implement. If your user base is growing, the time to start that conversation is before you hit 1,000 rps, not after.

At 1,000+ sustained writes per second, you should already have a scaling strategy documented and partially validated. At this rate, a single bad query, a new index, or a traffic spike can push you into degradation territory. The margin for error shrinks fast.

At 1,500+ sustained writes per second on production hardware, you're at the wall. Any growth from here requires horizontal scaling, and that's a fundamentally different kind of engineering effort.

The key word is sustained. Brief spikes to 2,000 rps during a flash sale are different from a steady baseline of 1,500 rps growing 20% year-over-year. It's the growth curve that should drive your planning timeline.

Conclusion

On a 16-core Ryzen 9 with a top-tier NVMe and 62 GB of RAM (hardware that would cost you $300-400/month in the cloud), a single PostgreSQL 18 node tops out at approximately 1,875 realistic transactional writes per second. With full durability, 5 indexes, multi-statement transactions, an audit trail, and production timeouts. On real production servers with standard SSDs, expect that number to be closer to 1,000-1,200.

That's still 86-162 million writes per day. More than enough for the vast majority of applications on the planet.

PostgreSQL is an exceptional database. This post isn't an argument against it. I've built my career on it, and I'd choose it again.

But the internet is full of inflated write performance numbers that set unrealistic expectations. When your application hits 1,000 transactional writes per second and struggles, you're not doing something wrong. You're hitting a real, physical limitation that most benchmarks conveniently avoid. The time to prepare for that ceiling is when you're at 500, not when you're already drowning at 1,200.

Know your real limits. Plan your architecture around honest numbers, not synthetic ones. And when someone tells you PostgreSQL can handle 100,000 writes per second, ask them: with how many indexes? With fsync on or off? With synchronous_commit on or off? With real transactions or bare inserts?

The answers will tell you everything.

The benchmark code is open source. Run it on your own hardware and see what your PostgreSQL can actually do. The numbers might surprise you.