A few small issues: - They call generate_ulid(now()). This returns the transaction timestamp, so all the timestamps will be the same. They should be using cloc

A few small issues: - They call generate_ulid(now()). This returns the transaction timestamp, so all the timestamps will be the same. They should be using clock_timestamp(). - It also appears the generate_uuid() function they're using (which is not explained) is implemented with PL/PGSQL and is quite slow. There is a native C extension called pg-ulid [1] which is much faster; about 15% faster than Postgres' gen_random_uuid(). - Using EXPLAIN ANALYZE to benchmark stuff is a bad idea in generally. It will not give realistic timings, and it has a lot of overhead. EXPLAIN ANALYZE is intended to debug a query plan, not benchmark it. Instead of using EXPLAIN, you can use COPY: COPY (SELECT ...) TO '/dev/null' (FORMAT BINARY); This has the advantage that it is more realistic, since the server has to actually serialize the results, so you get an approximation of that overhead. If you're using psql, you can enable timings and use \copy: \timing on \copy (SELECT ...) TO '/dev/null' (FORMAT BINARY); This will transfer the data from the server to psql, so it will include network time, which makes the benchmark more realistic. [1] https://github.com/andrielfn/pg-ulid https://github.com/andrielfn/pg-ulid