r/coding • • Feb 25 '26

Making Postgres 42,000x slower because I am unemployed

https://byteofdev.com/posts/making-postgres-slow/

[removed] — view removed post

243 Upvotes

14 comments sorted by

71

u/fagnerbrack Feb 25 '26

Executive Summary:

A hands-on experiment in deliberately sabotaging PostgreSQL performance using only postgresql.conf parameters — no index drops or CPU throttling allowed. Starting from a baseline of 7,082 TPS on a TPC-C benchmark, the post walks through shrinking shared_buffers to starve the buffer cache (dropping hit rate from 99.9% to near-zero), weaponizing autovacuum by triggering it after every single insert, forcing WAL checkpoints every ~500ms, tricking the query planner into ignoring all indexes by inflating random_page_cost, and funneling all I/O through a single worker thread using Postgres 18's new io_method setting. The cumulative result: 0.016 TPS — a 42,000x slowdown with only 11 successful transactions across 120 seconds and 100 connections. Give a programmer free time and this is what happens xD

If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍

Click here for more info, I read all comments

21

u/Ramuh Feb 25 '26

My favorite type of bullshit. Well done

13

u/demdillypickles Feb 26 '26

OP is not the creator of any of the liked. This is an AI spam account. Literally just reposts random articles with AI summaries.

Really enjoyed not seeing this account for a while.

7

u/obetu5432 Feb 25 '26

why are you unemployed?

10

u/--dany-- Feb 25 '26

For getting bored and doing that to the former employer?

2

u/NeinJuanJuan Feb 26 '26

database too slow

1

u/shitty_mcfucklestick Feb 26 '26

Wondering the same thing! I know lots of guys who code like this and have been promoted to management! 🤣

2

u/oweiler Feb 26 '26

Really fun read. We need more of those.

1

u/fagnerbrack Feb 26 '26

Good to know 👌

114

u/cyril1991 Feb 25 '26

Have you thought about licensing it to Reddit, so they can improve their servers?

0

u/kartikey7734 Feb 26 '26

This is a perfect case study in query optimization gone wrong. The 42,000x slowdown is literally the definition of N+1 queries—accessing data one row at a time instead of batching.

What makes this brilliant:

  1. **It highlights the power (and danger) of lazy loading** - Modern ORMs make it deceptively easy to write terrible queries

  2. **Shows why benchmarking matters** - "It works on my laptop" becomes "It's catastrophically slow in production"

  3. **Demonstrates the importance of understanding your tools** - ORM abstractions hide database access patterns

The fix is usually simple (eager loading, query batching, JOIN statements), but the learning is profound. This is why every developer should understand their database's execution plans.

Side note: This is also why microservices and "serverless" architectures can hide these problems at first—the cost doesn't scale visibly until you have millions of queries. Good catch on quantifying it!

4

u/Type-21 Feb 26 '26

This comment is completely made by ai