Если у вас вычислительные задачи на том контейнере, то есть немалая вероятность, что вам не удастся выиграть отказом от Docker.
Пожалуй, разве только если вы запускаете контейнер слишком часто. Тогда это будет иметь смысл. Но тогда вы неправильно пользуетесь Docker.

Попробуйте переселить тот контейнер на машину помощнее. А лучше даже распараллелить, увеличив количество экземпляров. В итоге, это, может быть, даже архитектурная задача.

На этот момент пока есть мысль выполнить разовую миграцию в одну целую таблицу при помощи хранимой процедуры, где будет алгоритм с 2-мя циклами (годам и месяцам), выполняющий INSERT INTO SELECT в новую таблицу.
Причем, новая таблица должна быть построена с партициями по годам и месяцам, чтобы решить предполагаемую проблему с количеством данных, из-за чего и возникла идея разбить на множество таблиц.
Альтернативно, можно выполнить дамп всех таблиц и "склеить" их при импорте.

Собственно, выполнив миграцию, можно будет самым обычным способом производить выборки логов в нужном диапазоне дат.

А, вообще, если у вас в логах хранятся метрики (история цифр), то подумайте о переходе на другие СУБД (аналитические, временных серий и пр.).

Когда пользователь ждет пока агрегатор выполнит свою работу - это нехорошо. Правильнее, чтобы первый захотел некоторый контент и сразу мог получить его, прямиком с БД, а в идеале с кэша частозапрашиваемого контента.
Для этого агрегатору необходимо регулярно выполнять свою работу независимо от посетителей, в фоне. Разумеется, пайплайн агрегатора должен заранее знать откуда заполучать контент или же одноразово получить список источников в начале, пройтись по ним и занести данные в БД. Затем регулярно обновлять с уже известных источников независимо от захода пользователей.

Ну а если в БД пусто и позарез нужно выдать контент, то остается плохой вариант - дать пользователю ждать, пока контент не будет скачан, обработан агрегатором и получен обратно. В данном случае, при попытке получения контента можно выдать сообщение, что мол, "Извините-с-с, заходите чуток позже" или же "Подождите 5 сек, я быстро-быстро". А когда свежий контент уже был обработан, то отправить назад контент по SSE/WebSocket. Или же short polling просто клиент будет периодично выполнять запросы к API с надеждой получить контент.
Вот здесь можно прочесть о способах взаимодействия

Поэтому я вижу такую архитектуру при работе с пользователем:

Client -> API -> cache/DB (read)
             \
              MQ
                 \
               [Aggregator]
                      \
                      DB (write)

Здесь [Aggregator] может означать как монолитный механизм скачивания-обработки, где все в одном, так и микросервисную архитектуру.

По мне, так бизнес-логику на Go писать не очень удобно и ее лучше осуществлять на более высокоуровневых языках. Так что в Go я бы реализовывал механизм скачивания контента и извлечения нужных частей, а в Python/Ruby/Perl и т.д. - логику самого агрегатора (смешение, композитинг контента).