Что выбирать: SQL vs NoSQL?
1) сильно сомневаюсь, что 32gb ram вам хватит на 20+млн записей, для редис
2)У редиса есть AOF при котором потери данных крайне маловероятны
3) Редис быстрый не потому что nosql, а потому что бд в ram 
4) при корректно построенных индексах и структуре бд на 20 млн мускул не тупит, у нас на одном продакшн проекте в таблице сейчас 100 млн и все отлично шустро работает. кстати таблица переехала из редиса, когда тому перестало хватать РАМа, после тюнинга мускула быстродействие не пострадало.
5) Как выше написали, если делать инсерты пачками, а не по одному, это значительно ускорит работу бд
6)у хетцнера диски очень любят сыпаться, крайне не рекомендую их сервера. Сопоставимые цены у OVH, при явно лучшем качестве
7) Как показывает мой опыт, корректно настроенный SQL достаточен в 99% случаев
Допустима потеря данных до 2%
Один из 50 insert'ов падает, и это приемлемо, я верно понял? 

БД (MySQL) при огромном количестве записей (ожидается более 20 млн записей) очень сильно начинает «тупить»
Если структура данных вполне определена и поддаётся секционированию, возможно можно разбивать инфу по таблицам по месецам/неделям/ и др. ( смотря какой поиск будет производится)

1. Хотите быть гибкими чтоб поменять редис-могно-sql, подумайте об абстракции, используйте шлюз между вызывающим кодом и хранилищем. ( в таком случае кеширующую прослойку можно легко внедрить при необходимости)
2. Напишите тест генерирущий кучу предположительных запросов на чтение и на запись (если проект будет развиваться — пригодится)

(оба пункта дадум вам ценный полезный практический опыт)

Большой поток инсертов можно решить буферизирование на клиенте, и вставлять кучу строк за одну зоманду — Хорошая оптимизация, подумайте, возможно в вашем случае это вполне приемлемо.

Мне больше нравится как первичное хранилище реляционка, редис/монго и прочее как промежуточно хранение агрегированной инфы или для кеширование.