Есть еще latency. Все решения ходящие в другой процесс по TCP/IP, по данному критерию тут же будут проигрывать чему нибудь in site типа SQL Lite. IMHO & AFAIK

И никакое in memory не поможет. К тому же, открути от базы данных целостность, и любая БД тут же по скорости приблизится к in memory ))).

p.s. Выбирал в свое время между Level DB vs SQL Lite - по тестам примерно аналогичные скорости. Но Levei DB 3-и года назад показался жутко сырым и Java драйверы были только от каких-то наколеночно-гаражных студентов. Прогресс и стартапы оно конечно хорошо, но иногда хочется надежности и предсказуемости )))

Года четыре назад, нужно было тестировать дисковую стойку. Админы под это дело выдали "валявшийся" 1-юнитовый сервер как раз с 256 Gb оперативки. Т.ч. оперативка нынче не проблема ))).

Другое дело, когда разрабатывал распределенную систему работающую на Амазоне, уткнулся в latency TCP/IP, даже locatlhost, не удаленный. И RMI (Remote Method Invocation) достаточно сильно тупил, и PostgreSQL нужной скорости не выдавала.
С RMI пришлось укрупнять вызовы, пропихивать на обработку в другой JVM сразу пачку заданий в 100 штук, значительно усложнился код, но в 100 раз возрасла скорость доставки данных. От PostgreSQL просто стал избавляться. В часте обработки, заменил PostgreSQL банально на сериализованные массивы просто в файлах на диске (сообтсвтственно БД заменилась на сильно "большой" атомарный /не стандартный!/ HashTable), в часте подготовки данных (где нужны были и insert'ы и select'ы) на SQL Lite.
Смотрел на Редисы, Memory DB, но:
1. Память хоть и не являлась "проблемой". Но деньги стоила. Т.ч. стоимость владения системой была бы выше (и так даже ценник за IP трафик от amazon'а уже начинал "кусаться", пару терабайт в месяц я один запросто "накачивал").
2. Никак не убирала проблемы огромной latency в TCP/IP. А при том, что ноды бы оказались еще и раскиданы в кластере, latency только бы выросло в разы. Плюс Ethernet трафик был бы крайне приличный.
Знаю одну реальную контору, админы жаловались, что узкое место в стойке - свитчи. Не справляются. Им даже пришлось шифрование трафика отключать, но не сильно помогло.

Меня вообще latency TCP/IP в процессе работы перестало устраивать. Т.ч. все кластерные идеи пошли лесом. Даже там, где изначально сделал разделение JVM-машин через RMI, пришлось API "укрупнять". Мне нужно было несколько тысячь-десятков тысяч различных авиа-маршрутов просчитать и сравнить (при этом разно "тяжелых", отдельные маршруты до десятков-сотни миллионов вариантов пересадок давали)

Можно конечно было-бы супер-пупер кластеризованную систему из тысячь одновременно работающих потоков соорудить ))), каждый на своем компьютере и пофиг на latency ))) но я просто код соптимизировал и вполне нормально на 4 процессорной ноде в десяток потоков все считал )))

Если поток данных большой и плохо поддается "батчингу', то сеть вполне может стать непроходимым узким местом.

(напрмер мне перед каждым Insert'ом нужно было еще сверится с БД и проверить данные пришедшие до этого Insert'а, т.ч. массовая вставка шла лесом или сильно усложняла /и замедляла/ алгоритмы)