Нечего даже и пытаться восстанавливать. Это потенциально опасно для данных. Если данные действительно важны, несите в фирму по восстановлению данных.

Можно построить архитектуру приложений так, что API будет работать преимущественно в режиме чтения с СУБД.
А другой процесс-воркер будет получать задачи через очередь сообщений и интенсивно писать в СУБД.
В API вместо блокирующего ответ клиенту парсинга нужно сразу слать задание в очередь сообщений. Тогда соединения не будут удерживаться подолгу, а почти сразу будут закрыты по отправке в очередь.
Все, что шлется в API для добавления в очередь, можно возвращать ответ 202 (Accepted).
Как только воркер выполнит задачу, он обновит результат парсинга в БД. А тем временем, при обращении по API информация будет считана с БД без каких-либо блокирующих операций.

То есть небольшой апгрейд состоит в схеме:
APIs (write) -> MQ -> Worker(s) -> DB
APIs (read) <-> DB
Так легко добавить любой компонент в случае большой нагрузки.

Ну и, необходимо замерять нагрузку, чтобы знать где узкое горлышко.

Есть еще Erlang, ну и языки поверх BEAM, полагаю.