Where database blog posts get flame-broiled to perfection
Alright, let's see what we have here. Another blog post about "scaleup." Fantastic.
"Postgres continues to be boring (in a good way)." Oh, that’s just precious. My friend, the only thing "boring" here is your threat model. This isn't boring; it's a beautifully detailed pre-mortem of a catastrophic data breach. You've written a love letter to every attacker within a thousand-mile radius.
Let's start with the basics, shall we? You compiled Postgres 18.0 from source. Did you verify the PGP signature of the commit you pulled? Are you sure your build chain isn't compromised? No? Of course not. You were too busy chasing QPS to worry about a little thing like a supply chain attack. I'm sure that backdoored libpq will be very, very fast at exfiltrating customer data. And you linked your configuration file. Publicly. For everyone. That's not a benchmark; that's an invitation. Please, Mr. Hacker, all my ports and buffer settings are right here! No need to guess!
And the hardware… oh, the hardware. A 48-core beast with SMT disabled because, heaven forbid, we introduce a side-channel vulnerability that we know about. But don't worry, you've introduced a much bigger, more exciting one: SW RAID 0. RAID 0! You're striping your primary database across two NVMe drives with zero redundancy. You're not building a server; you're building a high-speed data shredder. One drive hiccups, one controller has a bad day, and poof—your entire database is transformed into abstract art. I hope your disaster recovery plan is "find a new job."
Now, for the "benchmark." You saved time by only running 32 of the 42 tests. Let me guess which ones you skipped. The ones with complex joins? The ones that hammer vacuuming? The ones that might have revealed a trivial resource-exhaustion denial-of-service vector? It's fine. Why test for failure when you can just publish a chart with a line that goes up? Move fast and break things, am I right?
Your entire metric, "relative QPS," is a joke. You think you're measuring scaleup. I see you measuring how efficiently an attacker can overwhelm your system. "Look! At 48 clients, we can process 40 times the malicious queries per second! We've scaled our attack surface!"
Let's look at your "excellent" results:
update-one: You call a 2.86 scaleup an "anti-pattern." I call it a "guaranteed table-lock deadlock exploit." You're practically begging for someone to launch 48 concurrent transactions that will seize up the entire database until you physically pull the plug. But it's worse for MySQL on this one test, you say. That's not a defense; that's just admitting you've chosen a different poison.But the absolute masterpiece, the cherry on top of this compliance dumpster fire, is this little gem:
I run with fsync-on-commit disabled which highlights problems but is less realistic.
Less realistic? You've disabled the single most important data integrity feature in the entire database. You have willfully engineered a system where the database can lie to the application, claiming a transaction is complete when the data is still just a fleeting dream in a memory buffer. Every single write is a potential for silent data corruption.
Forget a SOC 2 audit; a first-year intern would flag this in the first five minutes. You've invalidated every ACID promise Postgres has ever made. "For now I am happy with this results," you say. You should be horrified. You’ve built a database that’s not just insecure, but fundamentally untrustworthy. Every "query-per-second" you've measured is a potential lie-per-second.
Thanks for the write-up. It's a perfect case study on how to ignore every security principle for the sake of a vanity metric. I will now go wash my hands, burn my laptop, and never, ever read this blog again. My blood pressure can't take it.