Postgres-grade Serializable at 20k+ ops/s — on a laptop. Don’t try this at home.

Hugo Vantighem — Sat, 23 May 2026 17:14:52 +0000

They didn't know it was impossible, so they did it. — Mark Twain

In the software industry, we've been raised with a dogma: you must choose between Massive Performance (NoSQL, eventual consistency) and Domain Rigor (SQL, strong consistency, serializable).

We are told that locks, latencies, and ACID properties are the natural enemies of speed. That if you want to scale, you have to let go of your business invariants.

I decided to test another hypothesis. And I broke the myth.

The Result: 20,000+ Validated Transactions per Second

This isn't a "fire and forget" ingestion log.

This isn't a volatile cache experiment.

What you see here is Business Transaction Durability:

Invariants validated — every business rule is checked before commit.
State persisted — every change is durably written to disk.
Strong Consistency — Serializable-level isolation.

At 20,000+ ops/s, we are not just talking about speed. We are talking about the ability to maintain absolute domain integrity under massive load.

And the kicker: this is running on a MacBook Air M3 — 8 cores, 16 GB of RAM, the same machine I write the code on. No 64-core server. No NVMe array. No datacenter rack. One laptop, fan barely audible, doing the work of a small cluster.

Why General-Purpose Databases Hit a Ceiling

Most databases are built for general cases. They treat every row the same way because they don't know your business.

This "Domain Ignorance" leads to generic row locks, MVCC bookkeeping, cross-table coordination, and massive overhead — costs you pay on every single transaction, whether your domain needs them or not.

Not Magic — Discipline

For the skeptics: this isn't sorcery. It's discipline applied to the right layer — designing the system so the hardware does exactly what it's good at, and nothing else.

I'm not reinventing the storage wheel. The foundation is Pebble, the same proven LSM-tree engine that powers CockroachDB. But the engine is just the floor. The real lever is the orchestration of the domain logic on top of it — and that's what Part 2 puts a name on.

A Note on the Benchmark Scope

I know what you're thinking. "20k+ ops/s? That must be an internal memory trick."

It isn't. To ensure these numbers reflect real-world usage, the benchmark covers the entire lifecycle of a business transaction:

Client-side serialization — the payload starts from the app.
Local communication — end-to-end roundtrip.
Server-side deserialization & parsing.
Business Invariants validation.
Disk persistence with full durability guarantees — fsync on every commit.

The workload: batch=1000, payload=1KB, single-node, single laptop. Here's the run, with the system-level disk stats captured live during the bench:

[23755.87 items/s] | items=1424000 | batch=1000 | payload=1KB | durability=FSYNC-ON

Live capture during the bench (batch=1000, 1KB, fsync ON). Disk on fire, CPU bored.

Two things jump out of that stats panel — and together they're the whole point:

The disk is screaming. Sustained 100–200 MB/s with the ⚡ markers firing almost every second. This is real fsync'd traffic hitting the SSD, not a memory cache pretending to be durable. If you pulled the power cord mid-run, every committed transaction would still be there on reboot.
The CPU is bored (~18% on an 8-core M3). The compute is idle while the disk pegs out — that asymmetry is the whole story.

And this isn't the ceiling. With bigger batches the same laptop pushes further; even at batch=1, it doesn't fall off a cliff. The full envelope is Part 2.

What's Next?

This is just Part 1. In a few days, Part 2 finishes the picture and lands the real punchline: business rules aren't a tax on performance — they're the contract that lets the machine fly. And the whole thing runs on hardware your team could expense, not a cloud bill that needs board approval.