DEV Community: Haik

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.