Зачитался я последнее время про Tarantool, интересно стало. Идея хорошая — код рядом с базой данных, хранимка в такой быстрой Redis-подобной среде. И что-то задумался — мы вот сейчас используем активно на работе Golang, собственно, мысль пришла что на Go написано много всего, в т.ч. и встраиваемых баз. А что если сравнить, например, Go+LevelDB (собственно, можно было бы и любую другую) против Tarantool. Тестировал еще Go+RocksDB, но там оказалось все немного сложнее, а результат примерно тот же на небольших данных. Тестировал простую задачу — HTTP сервер, при запросе — записать ключик в базу, достать его же по имени (без всяких проверок на race), отправить назад простенький JSON из этого value. Сравнил: go+leveldb, tarantool, go+go-tarantool, nginx upstream tnt_pass Забегая вперед — в моем ненаучном тесте выиграл Go+LevelDB за счет использования всех ядер процессора. Скорее всего, если запустить несколько Тарантулов и балансировщик — выигрыш может какой-то и будет, но не сказать чтобы значительный… Но, правда, тут уже надо будет репликацию делать или что-то подобное.  Но, в целом, Tarantool — очень впечатляющая штука. Обратите внимание: я сравниваю вполне конкретный случай, это не значит что во всех остальных случаях Go/LevelDB выиграет или проиграет.  Ну и еще: вместо LevelDB — вероятно, лучше использовать RocksDB. Итак результат (кратко)  4-10 = 4 потока, 10 одновременных соединений
10-100 = 10 потоков, 100 соединений  Обратите внимание Tarantool занимает только 1 поток CPU (вернее по виду 2), а тестировалось на 4-поточном CPU. Go использует по умолчанию все ядра и потоки. nginx lua tnt_pass взят из комментария  dedokOne (результат) wrk -t 4 -c 10 (4 потока, 10 соединений): Golang: Tarantool: Но, Тарантул занял примерно только половину ядер, так что, вероятно, скорость у них — примерно одинаковая.  Под бОльшей нагрузкой (wrk -t 10 -c 100) Тарантул остался на месте по RPS (а вот latency просела значительно заметнее чем у Golang, особенно верхняя часть), а Golang даже приободрился (но latency тоже просела, разумеется). Go: Tarantool: У Tarantool есть свои примущества: secondary index, репликация…  У Go же есть огромная экосистема библиотек (около 100 тыс по моим подсчетам, среди них и реализаций встроенных (и не очень) баз данных — море), и, как пример, тот же bleve дает полнотекстовый поиск (чего, насколько я понял, например, нет в Tarantool).  По ощущениям экосистема Тарантула беднее. По крайней мере все, что предлагается — msgpack, http server, client, json, LRU cache,… в Go реализовано в бессчетных вариантах.. Т.е., в общем-то, безумного выигрыша скорости нет. Пока что мой личный выбор остается в сторону Go, потому что нет ощущения что экосистема Tarantool выстрелит настолько сильно в ближайшее время, а Go — уже давно активнейше развивается. Код на Tarantool, конечно, короче, но в основном, за счет того, что ошибки обрабатываются языком. В Go можно тоже вырезать все err и останется примерно столько же. Может у кого-то есть другие мнения? Еще в комментариях заметили про атомарные обновления кода в Tarantool, но раз уж мы говорим про HTTP запросы — то мы (на текущем месте работы) используем endless для go и по нашим тестам (а у нас там тысячи запросов в секунду) — обновляем мы Go код без потери HTTP запросов. Пример в конце статьи. И если подробнее про тест: Golang: Tarantool: Под большей нагрузкой: Go: Tarantool: Исходники тестов: Go: Tarantool: Golang (атомарная заменой кода, без потери соединений): После этого можно сделать go build запустить и попробовать во время нагрузки делать go build; kill -1 $(cat server.pid) — в моих тестах потери данных не наблюдалось. В комментариях порекомендовали попробовать go+go-tarantool Попробовал: Меньшая нагрузка Большая нагрузка: Исходник: tarantool.lua: main.go: Нагруженные бэкэнды