Алексей

Наверное уже давно сгладилась разница и сейчас нет простого ответа - что вот этот движок хуже, а этот лучше. Они все примерно одинаковые по функциональности, по возможностям и т.п.
Скорее есть разница по качеству кода и степени поддержки со стороны разработчиков. Это вам уже поотвечали тут, я лишь уточню.
Коммерческие движки предполагают, что купив у них продукт, вы получите некий канал связи напрямую с разработчиками. Тем самым при возникновении трудностей можно с ними проконсультироваться или запросить помощь. По факту все не так радужно, зачастую поддержка продукта хромает, даже если вы заплатили деньги. А решение нестандартных задач все равно выполняется за деньги. Про качество кода и документацию - все также не очень радужно.
Open-source (мне не нравится слово бесплатное, это не так же) - это движки с открытым кодом, который можно скачать обычно бесплатно и без каких-то ограничений использовать для реализации своего проекта. Зачастую качество код и документация в таких проектах получше, чем в коммерческих, чисто за счет того, что это open-source. То есть всегда найдутся люди, которые найдут косяки и костыли, исправят их, опишут и т.п. Справедливо для больших и известных проектов. Но с поддержкой сложнее - найти ее можно только у сторонних организаций, либо на форумах и интернете. Тут уж как повезет с качеством. И спихнуть проблему на техподдержку зачастую тоже не удастся - надо быть к этому готовым.

Как уже сказали - Redis однопоточный, то есть запросы будут выполняться по очереди. Пока не сформирует данные для второго клиента, запрос первого не выполнится. Но следует понимать, что производительность Redis очень высокая. Настолько, что в случае 2 клиентов, один из которых 20 раз в сек пишет что-то в базу - вы просто не заметите задержки. Нормальная нагрузка для Redis это десятки и сотни тысяч запросов в сек, а то и млн.

Самые бескомпромиссные варианты на скорость чтения и записи - база данных Redis и подобные ей (Aerospike, Tarantool). Данные хранятся в памяти, их чтение и запись максимально быстрая. Эти базы NoSQL в виде ключ-значение, то собственно всю вашу задачу покрывает с лихвой. Ключ = номер телефона, значение = описание. Можно чуть усложнить базу данных , чуть изучив структуры даннных Redis - при желании конечно.
Единственное ограничение в случае Redis - количество ОЗУ на сервере. Под 1.5 млн записей по 200 байт понадобится больше 700МБ. Соответственно с ростом количества записей потребление памяти будет расти пропорционально. Впрочем сейчас можно найти недорогие сервера с большим количеством памяти, не то, что раньше. Потребление памяти можно распределить, используя кластерное решение, которые выглядит вроде интересным, но если честно - не очень удобным. По крайней мере не текущем этапе разработки. Надежность такой базы тоже можно увеличить, если сделать репликацию на другой сервер, где данные будут постоянно записываться на диск в режиме AOF - тогда потерять их будет сложнее, а работа с базой на мастере не будет замедлена небыстрыми дисковыми операциями. Можно этот AOF сделать и на одном сервере, если SSD - то нагрузка будет практически незаметная.
Если есть время и достаточно опыта в разработке - можно разобраться в аналогах, у которых ограничение в ОЗУ не так сказывается. Тот же Aerospike например оптимизирован под работу на SSD, а Tarantool может хранить в себе гораздо больше данных, чем позволяет объем ОЗУ, без особых потерь производительности (так заявляют).
Также у облачных сервисов Amazon / Azure / Google есть свои базы для key-value, можете изучить их стоимость, возможно вас устроит.

Теоретически вы так же можете использовать MySQL или PostgreSQL, структура не настолько сложная у вас, чтобы эти СУБД не справлялись с ними. Но их производительность все будет уступать Redis на порядок.