зыок, значит сформулируем исходное утверждение иначе - если вся база сидит в памяти (мы получили бонус на скорость чтения), то при активном изменении базы множеством клиентов данные должны из памяти синхронно скидываться на диск (в базу, случайный доступ) и дописываться в лог (линейно). Поскольку данные в памяти можно менять несравнимо быстрее, мы все равно будем сверху ограничены скоростью синхронной случайной записи на диск в файл данных, правильно? Не стали всё таки читать по ссылке? :-)

если вся база сидит в памяти, мы получили бонус на скорость чтения.

при активном изменении базы множеством клиентов данные не пишутся синхронно на диск (в базу, случайный доступ)

при активном изменении базы множеством клиентов данные пишутся последовательно в лог-файл (последовательная запись, чтения нет)

При этом асинхронно, в фоне, данные пишутся на диск (в базу, случайный доступ), на пишущие и читающие тразнакции это не влияет

Итог: Поскольку данные в памяти можно менять и читать несравнимо быстрее, но скорость зависит от записи в лог, мы все равно будем сверху ограничены скоростью синхронной случайной последовательной записи на диск в файл данных лога

И только если записей очень много, память переполняется буферами, и сервер не успевает асинхронно сделать изменения в файле базы, то только тогда производительность по записи упирается в скорость случайной записи в файл базы.
Это проявляется при апдэйтах случайных записей больших таблиц на сервере с маленькой памятью.

очень быстрыйКак итог:
- много ОЗУ (по максимуму)
- очень быстрые и небольшие диски в зеркале под ЛОГ
- медленные и объемные диски под БД Лучьше третий пункт переформулировать: "объемные и по возможности быстрые диски под БД" :-)

А то складывается впечатлдение, что диски под файлы данных обязательно должны быть медленные.

В конце концов, может ТС вообще сможет поместить на SSD всю свою 100-мегабайтную базу.