Ask HN: How can I load test PostgreSQL but avoid changing actual data?
There's a part of the code that performs UPDATE queries, but during load testing, I don't want these updates to actually change the state of the database. However, I still want the database to experience the full impact of the update — query planning, locking, I/O, WAL writes, etc. — so I can measure how it affects performance under peak load.
Is there a best-practice approach to achieve this?
So far, the most viable option I’ve found is to wrap the UPDATE queries in a transaction and then roll it back — that way, the queries still execute, but the state doesn’t change. Is this the right way to go? Does rollback introduce any performance overhead that would skew my results? Are there better or more realistic alternatives that simulate the full write path without persisting changes?
Thanks in advance!
I would expect it to be the other way around—since the transactions are rolled back and not committed, they would have significantly less performance impact. But I’m working from an academic model of the database.
very old school approach:
Misuse sql VIEW[3][4] to generate a temporary parallel table setup. Testing database separate from production database would be 'better', IMHO.
-----
[0] pgreplay-go : https://github.com/gocardless/pgreplay-go
[1] python locust : https://miguel-codes.medium.com/unconventional-load-testing-...
[2] pgbench load testing :
----------------------------[3] : a) https://hashrocket.com/blog/posts/materialized-view-strategi...
[4] : https://en.wikipedia.org/wiki/View_(SQL)