d'Ivan

Асинхронное исполнение кода позволяет более эффективно использовать процессорное время.
Если взять синхронный сценарий исполнения, то какое-то время поток приложения загружает процессор работой, далее обычно наступает ситуация, когда поток приложения ждет завершения какой-то операции ввода\вывода. Это может быть ожидание срабатывания таймера, ожидание данных от сетевой карты, ожидание пользовательского ввода и т.п. Пока происходит ожидание поток приложения не использует процессор. В некоторых случаях это нас устраивает, если другой полезной работы мы не можем совершить. В других ситуациях мы хотим одновременно что-то делать, например иметь возможность обрабатывать клики мышкой пользователя в то время как идет запрос к БД, например.
Тогда мы задействуем асинхронный подход. В этом случае когда поток приложения доходит до ожидания окончания операции ввода\вывода, он не ждет а может быть использован для другой работы, а в момент когда закончится операция ввода\вывода и поток не будет занят другой работой, он сможет продолжить исполнение кода с того места на котором остановился.

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

пакет это целостная сущность
если у вас два пакета не могут работать друг без друга - это один пакет

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

Похожую задачу решил для себя иначе.

Поле в БД сделал уникальным по которому должна была идти проверка.

При импорте делаю только INSERT. В итоге данные или записываются или нет и можно распараллелить :)

1 млн записей на слабеньком сервере за +/- 1-3 минуты выполняется.

DUPLICATE KEY UPDATE работает по уникальному индексу, который можно (и нужно) навесить на группу полей.

Буду довольно резким, но зато без воды:
- облачные провайдеры не умеют в магию, только в создание ресурсов
- реляционные базы даже сегодня умеют только в вертикальное масштабирование
- да, думать приходится самостоятельно
- для облегчения жизни можно использовать Read Replicas, но готовьтесь к задержкам
- спайковую нагрузку реляционные базы выдерживать не умеют (да и остальные делают это из рук вон плохо)

Рекомендации:
- планируйте масштабирование
- научитесь понимать как используются ваши данные
- научитесь в микросервисы (и не по тому что это популярно, а по тому что так происходит изоляция данных)
- научитесь в другие виды баз данных, например то же DynamoDB, хотя если не вникать то можно огрести еще больше проблем
- вспомните что есть кэширование
- прочитайте что есть такие паттерны как CQRS
- научитесь в проектирование PWA (Progressive Web Applications)
- выбросите это все по тому что это будет очень дорого по итогу

Прочитать документацию к модулю sqlite3. Должно стать понятно, что fetchone - метод курсора, а не соединения.