d'Ivan

Перевод в HSL, и смотрим на порог L (вроде).
Например так.

Причем тут OpenCV непонятно

WIP
(Work in progress)

11 миллионов inserts в день - это 127 в секунду. При такой нагрузке справится любая современная БД. Ну я не знаю таких чтоб не справлялись. Делайте только короткую буферизацию и batch-insert пачками по 100 - 1000 чтобы оптимизировать сетевой roundtrip.

Есть специализированные NoSQL системы такие как RocksDb, Tarantool в которых именно много оптимизаций сделано было для быстрой вставки. Они выдерживают и во много раз быстрее.

И в данной задаче нужно также спросить бизнес - как быстро данные нужны к чтению пользователя. Нужно сию секунду чтоб они отобразились на UI или можно подождать пару минут или часов.

При такой постановке задачи лучшим вариантом СУБД будет та, которую знают и умеют обслуживать ваши админы.
С таким объёмом вставок справится любая мейнстримная на правильно подобранном железе. Что ещё вы собираетесь делать с этими записями нам неведомо, посему на выбор повлияеть не может.

Kotlin как и все JVM-основанные языки имеет сложный рантайм. Который обладает способностью прогреваться от постоянных запусков. И поэтому чтобы точно и уверенно замерять перформанс - нужно правильно подходить к проблеме. Например использовать JMH для изммерений.

А для редких (одноразовых) запусков Python действительно может быть быстрее. Это я сам наблюдал в AWS-Lambda.
Функция лямбда которая вызывается 1 раз в сутки должна быть написана на чем-то вроде Python/NodeJS.

1. Нет, либо нет в 99.9999% случаев
2. Да, чтобы ограничить то, на скольких OS тредах может расположиться рантайм. Это прямо влияет на CPU-bound задачи и почти не влияет на IO-bound. Например, у тебя есть функция, которая перемножает матрицы. В канал поступают матрицы, есть 10 горутин, которые читают оттуда и умножают матрицы. Очевидно, что если GOMAXPROCS будет == 1, то все эти горутины будут жить на одном треде и будут "мешать" друг другу, задействуя не более одного ядра процессора. Если GOMAXPROCS будет 10, то каждая горутина может расположиться в отдельном ОС треде и считать себе там матрицы на "собственном" ядре.
3. Увеличится канал (sic!). Канал — это очередь. Канал без буфера — это "очередь", в которую можно добавить элемент только если с другой стороны этот канал кто-то пытается прочитать. Если такого нет — горутина будет ждать, пока этот канал кто-то захочет прочитать и наоборот, если кто-то читает канал, а с другого конца никто туда не пишет, то горутина будет ждать до тех пор, пока в канал кто-то не захочет записать. Если в канале есть буфер, то это уже становится полноценной очередью. Есть N слотов, если кто-то пришёл записать в канал, канал никем не слушается и там есть хотя бы один свободный слот — этот "кто-то" запишет в канал и пойдёт по своим делам и только если в буфере нет свободных слотов, то этот "кто-то" будет ждать, пока слот освободится. И наоборот, если кто-то слушает канал и в буфере канала уже что-то есть, то он сразу забирает первый на очереди элемент и уходит. Обычно это делают, чтобы сгладить нагрузку. Например, у тебя есть парсеры, которые что-то парсят, чтобы потом записать на диск. Но диск — штука непредсказуемая, может записать за 1мс, а может тупить 20мс. Довольно странно, если парсер будет ждать диск эти 20мс, хотя у него есть работа, которую он может выполнять прямо сейчас. Для этого можно создать буфер, куда парсер будет кидать данные СРАЗУ, а горутина, которая пишет на диск, заберёт их "когда-нибудь потом", когда диск перестанет тупить.

Как мне кажется вы не правильно ставите задачу. По сути менеджеры и разработчики решают разные задачи.
Поэтому для разработчиков phpmyadmin а для менеджеров как вы и сказали самописное приложение с возможность быстрого ввода карточек и несколькими отчетами.

Во-первых, while блокирует воркер так же, как и join. Во-вторых, Flask не предназначен для многопоточности и её в нём следует избегать. Лучше использовать асинхронность или очередь задач.