Сергей П

cur.execute(f'INSERT INTO result(name) VALUES ({data["Name"]})')

Так нельзя подставлять параметры в SQL-запрос по ряду причин. Ваша ошибка из-за отсутствия кавычек при такой подстановке, но даже если поставить кавычки в форматную строку так делать нельзя. Найдите любой простой отдельный работающий пример вставки в бд с передачей параметра и посмотрите. Таких в сети миллион. Можно ещё погуглить как правильно передавать параметры в sql-запос. а как неправильно и почему.

Добавьте в каждую таблицу поле с таймштампом и ставьте туда свежее значение при создании и каждом апдейте записи. Нужно сделать индекс на это поле, тогда выборка всех изменений в БД от конкретного момента (момента последней репликации) будет извлекаться практически мгновенно. Число запросов будет соответствовать числу таблиц в БД.
Синхронизацию можно делать сколь угодно часто, поскольку изменившихся данных будет не много, а чаще всего их не будет вовсе. Выборка происходит по индексу, а значит очень быстро, особенно если ничего не изменилось.

В локальной БД сохраняйте дату последней репликации в отдельной таблице.
Имейте в виду, что обратная репликация из оффлайн БД в основную уже не будет такой простой. Во-первых нужно что-то придумывать с генерацией идентификаторов для новых записей. Возможно придётся переходить на 16-битные идентификаторы (GUID), чтобы они не пересекались с основной базой.
Ещё нужно понимать, что в оффлайн режиме у вас может оказаться недостоверным время на локальной машине.
Если на локальной машине есть доступ к GPS, то можно снизить число негативных последствий, но не предотвратить их вовсе.
Если вам критично не перепутать время правки записей и первоисточник изменений из-за неточности локального времени, то тут надо будет предпринимать меры для решения этой проблемы, и, есть вероятность, что придётся идти на серьёзные компромиссы.
Если у вас будет много локальных клиентов, которые будут работать в оффлайн-режиме, то ситуация усугубится многократно. Минимизируйте возможность правки общих данных клиентами из оффлайн-режима.

Помните, что GPS сейчас не гарантирует достоверного времени на локальной машине, поскольку в некоторых регионах военное положение, а подразделения РЭБ в куче мест ставят помехи и искажают сигналы со спутников. Часы могут сильно врать.

self.cursor.execute("SELECT * FROM table1 WHERE colum1 LIKE ?", (f'%{age}%',)).fetchmany(1)

Так устроен индекс. Он строится в первую очередь по первым символам и в последнюю по последним.
Если вы подменяете % начало, то индекс просто не будет работать.
Разделите ФИО на отдельные компоненты и сделайте отдельный индекс для имени, тогжа ваш кейс будет быстрее работать.
У вас же фактически происходит полный перебор базы без индекса.

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

К соседнему ответу могу добавить.
Если Id у вас формируется автоинкрементом, то можо ограничить выдачу select-запроса одним элементом и указать обратный порядок сортировки по нужному вам полю.

sqlite БД - это просто файл, чтобы подключиться к такой БД можно скачать его или примонтировать файловую систему сним к локальной, например, через SSH. В случае больших БД будут проблемы с производительностью. Если вам нужно делать это штатно, регулярно, в проде, да еще и с разных клиентов, то использовать надо какие-то другие БД, а не sqlite.

Ещё можно сериализовать\десериализлвать этот список в \из json.

huge_string = json.dumps(huge_list)
restored_list = json.loads(huge_string)

Если вам зачем-то нужен rowid, скорее всего вы делаете что-то не так. Для чего он вам нужен?
В реляционных БД положение в таблице (не в выборке, а именно в таблице) ничего не значит. Вы не должны этим управлять и не за чем получать это положение. Уверен, есть другие способы достичь того, что вы там пытаетесь достичь. К примеру, если вам нужно узнать сколько пользователей имеют кэш меньше вашего, то так и запрашивайте:

SELECT count(*) 
FROM users u 
WHERE u.cash < (SELECT cash FROM users WHERE id = :my_user_id)

Если нужен какой-то рейтинг беднейших игроков до вас включительно, то можно использовать сортировку:

SELECT u.id, u.cash 
FROM users u 
WHERE u.cash <= (SELECT cash FROM users WHERE id = :my_user_id)
ORDER BY u.cash

Очередность выборки по индексу одинаковых значений не гарантирована. Если нужна стабильност ьпорядка выборки, добавьте вторым параметром сортировки обычный уникальный идентификатор, тогда люди с одинаковым кэшем не будут от запроса к запросу меняться местами.

Если делать запрос, то результат тот же.

А какой запрос вы делаете? Добавьте в него конструкцию `LIMIT , ` и получайте данные порциями.
Нужно посмотреть ещё ваш запрос. Вдруг там full join и всё, само собой, не помещается в память.