Сергей Соловьев

Либо кэшировать (что не особо трудно), либо храни это в сессии

Почитал лицензионное соглашение (яндекс переводчик)

4. Запрещается разрабатывать какие-либо производные версии, модифицированные версии или версии сторонних производителей для распространения на основе DESTOON полностью или в любой части.

Я не юрист, поэтому как понял: Будешь распространять - накажут.

Подключаешь их как статические файлы и отдаешь

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

Создаю Channel и BackgroundWorker, который из этой очереди читает. В эту очередь кладутся объекты по типу InsertContext. В ней хранится аргумент (данные для вставки), поле для результата и Task, который кончится по окончании.

Работа bw организуется так (в вечном цикле):

1. Читаем первую запись из Channel (infinite timeout)
   
2. Создаем TaskCompletionSource с таймаутом и пока он не кончился читаем записи из Channel (без ожидания)
   
3. Собираем все собранные данные
   
4. Записываем их в БД
   
5. В каждый элемент записываем результат и уведомляем о готовности
   

Бесшовно добавить эту функциональность можно с помощью декоратора.

Единственная проблема в данном случае - ошибки вставки. Если делать это единой транзакцией, то ошибка в 1 инвалидирует все. Но это можно обойти fallback'ом - если произошла ошибка, то вставляем по одному и ошибку возвращаем только тем, у кого они возникли

Потому что, здесь вступает в игру такое понятие как амортизированная сложность. Для динамических массивов, которые увеличиваются в несколько раз (т.е. не + 10, а *2 например), амортизированная сложность - O(1).
Поэтому, у тебя O(n) * O(1) = O(n) (амортизированное)

сид

У каждого поисковика свой URL для поиска. Для яндекса (по крайней мере у меня): https://yandex.ru/search/?text=
Их надо просто найти (идешь в поисковик нужный, делаешь любой запрос и смотришь в адресную строку)

Нельзя это сделать.
Причин много:
1. Все данные хранятся не в 1 файле, а в нескольких
2. В файлах хранятся не вот уже готовые данные, а множество различных кортежей - для MVCC. А без понимания ID транзакции (которая в другой БД будет иной) они бессмысленны. То есть, переложив физически файлы ты получишь белеберду
3. В Postgres нет возможности приаттачить файлы. Есть возможность INSERT/COPY, сдампить, но файлы напрямую нельзя. (нет такой опции в Attach)
4. В файле хранятся не сериализованные в независимом формате данные, а (грубо говоря) структуры C. Как они располагаются зависит от endianess, компилятора и т.д.
5. Даже если ты это все сделаешь, то не факт, что различные OID сойдутся - т.е. таблица будет хранить OID, которого в другой БД не существует

Если хочешь ускорить процесс, но используй pg_dump с ключом -fd (специальный формат), а в pg_restore -j NJOBS - распараллеливание (NJOBS - кол-во воркеров).