Артем Черепахин

Добрый день. СУБД под ваши нагрузки и правда можете выбирать любую. Лишь бы секционирование таблиц поддерживало. Postgres- очень хороший выбор. Есть нюанс Postgres, в некоторых случаях, может зависит от прямоты рук(т.е. как вы составите sql запрос). Как и у любой другой БД, есть свои особенности, с которыми вы можете встретиться, а можете не встретиться.
Ключ category+key вместо ID - не очень хорошая идея. Хотя бы поскольку только category имеет 100 символов, еще и key в придачу явно не пустой. Т.к. это первичный ключ по ним будет построен индекс. Ну и представьте, как будут выглядеть листовые блоки в индексах- при поиске в индексе нужного ключа придется по-битово сравнить 100 символов. Не критично, но идея не очень.
Если category повторяется- нормализуйте таблицу(Т.е. значения category вынесите в отдельную таблицу(сущность)) и в таблице MainTable храните внешний ключ(id ключа).
Смысла в поле key не вижу.

Средствами реляционной БД и если не критична скорость вставки, то можно попробовать реорганизовать таблицу со строками
{"1": [1,5,11,15,22,34...], "5": [55,44,22,67]}
к виду {1:["1"], 5:["1"], ...., 22:["1", "5"]}, т.е. теперь первым стоит значение для проверки, потом массив ключей- поменять местами ключи со значениями.
Делаете 1 индекс.
Жрать ресурсов будем меньше+ скорость поиска, усложняется доступ к бывшим ключам вхождения("1", "2",...).
Можно попробовать создать 2 таблицы: первая просто число, которое нужно искать(скорость поиска О(1)+высота дерева в индексе), а вторую с ключами вхождения и внешний ключ к первой.