Задача. Приложения, сделанные в Lovable, хранят данные в Lovable Cloud. Если владелец хочет держать базу данных в собственном проекте Supabase, нужно перенести таблицы, строки и учётные записи пользователей так, чтобы никому не пришлось регистрироваться заново.
Выгрузка. Lovable выгружает всю базу данных одним файлом pg_dump, не чаще раза в день. Файл двоичный и сжатый, поэтому SQL Editor не может принять его как есть. Я разделила его на структуру, данные и права доступа, а потом нарезала каждую часть на куски примерно по 15 КБ: если вставить больше, редактор зависает. Куски выполнялись по порядку в новом проекте, без pg_restore.
Проверка. Каждую цифру я посчитала с обеих сторон SQL-запросами. Структура совпала один в один: 30 таблиц, защита на уровне строк в 15 из 15, 15 политик доступа, 20 внешних ключей, 6 функций, 1 триггер и 1 хранилище файлов (bucket). Строки тоже совпали: записи 77 из 77, клиенты 25 из 25, собаки 26 из 26, лист ожидания 9 из 9, сообщения 25 из 25. Пользователь перенёсся с хешем пароля, идентичным исходному, а собственная функция базы данных приложения отработала в новом проекте и заполнила демо-таблицы.
Вручную. Задания по расписанию (pg_cron) хранятся в системной схеме, их нужно создать заново. Права для внутренней роли Lovable в Supabase не существуют, поэтому их пропускаем. Серверному коду, который использует сервисный ключ на хостинге Lovable, нужны новые ключи там, где работает сайт, и их задаёт владелец. Права для ролей API сохранены, это важно после изменения в Supabase от 30 октября 2026 года.
Границы. Сам сайт на новую базу данных не переключали. В настоящем проекте это последний шаг, его делают в собственном аккаунте Supabase и на хостинге владельца. Пароль от базы данных и ключи вводит сам владелец, поэтому ко мне они не попадают.