Small Datum

This post has results for the  Insert Benchmark  on a small server with a cached workload. The goal is to compare new Postgres releases with older ones to determine whether they get better or worse over time. The results here are from the newest small servers in my test cluster -- an  ASUS PN53 . This work was done by  Small Datum LLC . The workload here has low concurrency (1 or 4 clients) and the database is cached. The results might be different when the workload is IO-bound or has more concurrency. Results were  recently shared  from tests run on an older small server.  tl;dr There are no regressions from Postgres 16.3 to 17beta1 for this benchmark All Postgres versions have too much variance on the insert rate for the l.i1 and l.i2 benchmark steps. While tuning fixes that is a too frequent response, I spent much time trying to fix this via tuning last year without success. This has not been a problem for modern MySQL and one example is here  (equivalent Postgres graphs are here

This has results from the sysbench benchmark for MariaDB and MySQL on a new, small server with a cached and low-concurrency workload. For MariaDB I tested LTS releases from 10.2 through 11.4. For MySQL I tested 5.6, 5.7 and 8.0. The results from MySQL here are a good reason to use changepoint detection to spot regressions early, like that provided  by  Nyrkiö . This work was done by  Small Datum LLC  and sponsored by the MariaDB Foundation. Previous posts shared results from older, small servers: here  and here . The results here are similar. My standard disclaimer is that sysbench with low-concurrency is great for spotting CPU regressions. However, a result with higher concurrency from a larger server is also needed to understand things. Results from IO-bound workloads and less synthetic workloads are also needed. But low-concurrency, cached sysbench is a great place to start. tl;dr MySQL suffers more from performance regressions than MariaDB Modern MariaDB is 10% to 30% faster than m