Как клонировать терабайтную базу Postgres за десять секунд

Каждый бэкендер хотя бы раз ронял стейджинг кривой миграцией или тестировал тяжелый SQL-запрос на синтетических данных из пяти строк, а в проде получал глухой lock таблицы на полчаса. Тестировать на реальных объемах данных всегда сложно и дорого: терабайтную базу тяжело развернуть локально, а держать десять полных копий в облаке для каждого разработчика влетает в копеечку.

Инженеры из Postgres.ai решают эту проблему утилитой Database Lab Engine (DBLab). Проект дает возможность делать тонкие клоны Postgres любого размера буквально за секунды, не расходуя под каждый клон терабайты диска.

Что под капотом

Вся магия тонкого клонирования держится на механизме Copy-on-Write (CoW). По умолчанию DBLab использует файловую систему ZFS, но умеет работать и через LVM.

Схема простая:

• Движок держит актуальный базовый снимок данных (PGDATA), который синхронизируется с основной базой через репликацию, дампы или физические бэкапы (WAL-G, pgBackRest).
• Когда разработчику или пайплайну в CI нужен инстанс базы, DBLab создает моментальный снимок (snapshot) и поднимает изолированный Postgres в Docker-контейнере.
• Все операции записи идут в отдельный CoW-слой. Базовые файлы не меняются, поэтому клонирование 1 ТБ данных занимает около 10 секунд и требует всего несколько мегабайт диска на старте.

На одном сервере можно запустить десятки таких независимых баз, и разработчики смогут смело выполнять в них DROP TABLE или прогонять деструктивные миграции без риска сломать что-то коллегам.

Что умеет DBLab

В репозитории собрана база для автоматизации работы со снимками данных:

• Ветвление баз данных (database branching). Можно переключаться между разными ветками и временными метками, откатывать изменения командой reset и возвращаться к нужному состоянию.
• Поддержка версий PostgreSQL с 10 по 18, включая популярные расширения вроде pgvector и HypoPG.
• Встроенные механизмы защиты: автоматическое удаление старых неиспользуемых клонов по таймауту и retention-политики для снимков.
• Работа с управляемыми облачными базами. Если вы сидите на AWS RDS, GCP Cloud SQL или Supabase, где нет прямого доступа к файловой системе, DBLab можно развернуть на отдельной виртуальной машине рядом и настроить периодическое автообновление данных.
• Готовые интерфейсы управления: REST API, консольная утилита dblab CLI и веб-интерфейс.

Практические сценарии

Тестирование миграций в CI/CD

Перед выкаткой релиза пайплайн поднимает свежий клон реальной прод-базы, накатывает миграцию и замеряет время выполнения и блокировки. Если миграция берет эксклюзивный lock на тяжелой таблице или падает с ошибкой, пайплайн сразу сигнализирует об этом. После теста клон моментально удаляется.

Проверка сложных SQL-запросов и гипотез

Оптимизировать медленный запрос на пустой базе бессмысленно: планировщик Postgres выбирает совсем другие планы выполнения на 10 строках и на 10 миллионах строк. Клон в DBLab дает честный EXPLAIN (ANALYZE, BUFFERS) на продакшн-объемах данных без риска перегрузить боевую базу.

Проверка кода от LLM

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

Кому проект пригодится

Если у вас в проекте база весит пару гигабайт, городить инфраструктуру с ZFS и DBLab вряд ли есть смысл, проще обойтись обычным дампом.

Но если Postgres разросся до сотен гигабайт или терабайтов, а команда тратит часы на ручную подготовку тестовых сред и боится каждой миграции, Database Lab Engine сбережет массу нервов и денег на облачной инфраструктуре.

Исходный код движка открыт под лицензией Apache 2.0. Попробовать Community-версию можно на своем сервере по официальному руководству в документации или протестировать публичное демо на demo.dblab.dev.