Это легко "исправляется" настройками, но так лучше не делать Учитывая, что нужен "простой поиск", предполагаю, что будет необходимость строить пагинацию чуть ли ни на 2-3кк элементов
Я бы сказала что ее сила не в том что в нее умеют, а в том что она хороша для всего одинаково. А пока первую версию не запустишь обычно сложно предугадать в какую сторону БД укреплять придется
Дефолтная в плане — по дефолту выбирается как база данных. Я всегда сначала выбираю постгрю, а уже потом меняю, если что-то не работает или нужна другая специфика. Постгря покрывает 99% нужд, потому что банально умеет управлять структурированными данными и строить индексы
Кстати по постгрес, если в таблице A 100 записей, в таблице Б 1млн записей, будет ли таблица А выдавать худший пинг в сравнении если бы таблица Б не существавала?
Почему она должна тормозить?) В ластике есть bulk insert и он все кидает в фон. Да и в дополнение к этому можно еще настроить как часто обновлять индекс (и не только), чтобы было незаметно все для юзера
Просто у меня сложилось уверенное ощущение, что по мере забивания таблицы одной, скорость в таблице с значительно меньшим кол-вом данных падает) Не замерял. Поищу тогда почему так еще может происходить.
Это больше вопрос про одновременные запросы на мой взгляд. Если вечная очередь в большую таблицу, то запрос в маленькую без джойнов упрется в эту очередь