/* Co-author of Nancy CLI is here. */ Michel, I'm sure you mean pgbench, since you've added its support to Nancy CLI (thank you!) :) It's easy to mix though, s

/* Co-author of Nancy CLI is here. */ Michel, I'm sure you mean pgbench, since you've added its support to Nancy CLI (thank you!) :) It's easy to mix though, since we embed both (pgbadger is for log analysis when during experiments we are "okay" to turn the full query logging on -- it's a great tool being developed for years; it can produce JSON, so it's machine/integration-friendly). And yes, it's quite convenient in many cases to use pgbench, when logs collections is not an option due to some reason -- instead of workload replay we can use workload simulation, based on underdtanding how every query group from pg_stat_statements looks like (first of all, the main important thing is % of calls in overall picture). It's good that pgbench allows to set "weights" for every workload "piece", using multiple -f options and @weght (for example, "pgbench -f tx1.sql@20 -f tx2.sql@80", etc). We use this approach a lot. But I also believe in workload replay approach. Cool to see pgreplay-go, we'll definitely check it out and try! "Database experiments" is a very important and underestimated topic. Database change management methodologies (for open source products) are very weak compared to CI/CD, and other tech areas -- I hate to see how changes are being made without proper preparations and thorough testing. Improvements are definitely needed and it's great to see new tools!