А куда деваться?
База данных это много операций с памятью. Модификация этих структур должна быть атомарна (возможность менять несколько полей и не получать частичные изменения от других потоков).
Значит нужны мьютексы или хитрые lock-free алгоритмы (которые приводят к увеличению использования памяти и мы теряем процессорный кеш).Если мьютексов мало, то производительность на 1-4 потоках выше.
Барьеры дорогое удовольствие: http://kristiannielsen.livejournal.com/17598.html
Обратно, если мы исполняем одновременно сотни или тысячи потоков, то один горячий мьютекс сводит производительность на нет (например в mysql 4.1 или старых посгресах): работают 1-2 ядра процессора, остальные не используются. Как чинить такие проблемы? Разбивать мьютексы не несколько: вместо одной большой структуры делаем десяток структур, самые горячие структуры защищаем отдельными мьютексами. Например вместо одной точки выдачи новых значений auto_increment делаем несколько генераторов нового значения с разным смещением (offset).
Приходим к тому что новое решение может использовать современные процессоры.
В обычные 2U влезает 2-4 сокета, Intel предлагает процессоры с 12ти ядрами, amd с 16ти.
Итого получаем 48-64 честных ядра и 96 с гипертредингом, который с ростом количества ядер становится более эфективным.
Значит горячие мьютексы из mysql 4.1 надо размножить минимум в 100 раз чтобы максимально эфективно использовать дешёвое серверное железо. Если брать дорогое железо (те же power, на которых MariaDB показывала 1 миллион запросов в testbench, содержат до 1024 потоков на исполнение).
Итого, даже если производительность одного потока будет в 3 раза меньше, за счёт 100 ядер процессора мы получим в 30 большую производительность на современном железе, чем мы имели на старых версиях mysql/postgresql
