NickBor

Конкретный ответ на ваш вопрос в данной формулировке дать нельзя. Многое зависит от структуры БД, от сценариев работы с ней, интенсивности запросов, соотношения запросов на чтение к запросам на запись и т.д. и т.п. Вероятнее всего, это вопрос не к СУБД, а к архитектуре вашего приложения. В целом, у меня в одном из проектов запросы на чтение по индексу из таблицы с 23 миллиардами записей укладывались в десятки миллисекунд при стандартных настройках и не особо мощном сервере.

Если у вас большой объем показаний датчиков с временными метками - то стоит присмотреться к специализированным БД

Огромные таблицы однотипных и упорядоченных по времени данных - это моветон. Партиционирование таблиц по дням/месяцам и схлопывание старых данных в агрегаты должны помочь - именно так, например, происходит в БД Заббикса.

Вряд ли скажут точно.
Скорость запроса зависит от всего. От размера конкретной таблица, от того какие данные, причем важно и тип и их схожесть, чтобы было проще индексы строить.
И от скорости ssd
Но я бы сказал, что 100-300 гб это далеко не бигдата. Это просто большая база, с которой справится и mysql и postgres, тем более что взяв сервер с 128гб оперативки, почти треть можно в памяти кешировать.

В вашем случае - без перфоманс тестов никто не скажет даже примерный порядок.
P.S. И да, если ваши данные в основном числа (таймстамп и числовые показатели, то time series data bases могут с этим справиться лучше). С другой стороны они не так популярны и возможно не так развиты.

Попробуйте одну из TSDB, как указал Владимир Куц .

В частности, хранилище VictoriaMetrics. В качестве языка запросов применяется PromQL.

Возможность использования в качестве долговременного хранилища данных, подключенного к Prometheus и Grafana.

Что касается преимуществ по отношению с другими, то сходите по ссылке выше.