Большинство современных баз данных — MySQL, Postgres, Oracle — устроены как монолит. Вся логика и данные живут на одной машине. У этого подхода куча проблем: при неправильной настройке сброса кеша транзакция может бесследно исчезнуть при перезагрузке, диск умирает — данные пропадают, читающие реплики — это полные физические копии всей базы, которые долго создавать, а тяжёлый аналитический запрос легко кладёт на лопатки чувствительные к задержкам транзакции. Всё упирается в то, что журнал упреждающей записи (WAL) и файлы данных привязаны к одному железу.
Lakebase решает это радикально: он выносит WAL и файлы данных с локального диска в отдельные, независимо масштабируемые облачные сервисы. Вычислительные инстансы Postgres становятся stateless — они не хранят данные, их можно запускать, останавливать и клонировать мгновенно.
WAL превращается в распределённый сервис SafeKeeper. Транзакция считается завершённой, когда запись реплицирована через кворум узлов по протоколу Paxos. Никакого риска потерять данные из-за сбоя диска или кривого fsync. Сами файлы данных уходят в PageServer — это распределённое хранилище, которое асинхронно применяет изменения из WAL и материализует страницы в дешёвое облачное объектное хранилище (озеро данных). Чтение идёт через многоуровневый кеш (память + локальный диск), и только при промахе — запрос к PageServer. На практике задержки чтения неотличимы от монолита.
Такая архитектура даёт бесконечное хранилище в облаке, эластичные «серверлесс» вычисления (можно ужать до нуля в простое), гарантию нулевой потери данных, упрощённый High Availability без поддержки второго физического клона и, что особенно круто, мгновенное ветвление базы — как в Git, за секунды, без копирования терабайтов.
Но главная фишка — LTAP (Lake Transactional/Analytical Processing). Раньше аналитика и транзакции жили на разных копиях данных, соединённых хрупкими CDC-пайплайнами. LTAP хранит одну-единственную копию данных в открытых колоночных форматах (Delta/Iceberg на Parquet) прямо в объектном хранилище. PageServer при материализации сам транскодирует строки Postgres в колонки Parquet, не нагружая транзакционный движок. Когда приходит аналитический запрос, он сначала берёт у Postgres дешёвую метку LSN (номер в логе), читает основную массу данных из объектного хранилища и добирает только самые свежие, ещё не материализованные изменения через PageServer. Postgres не участвует в аналитике — транзакции не тормозят. Никаких списков «реплицируемых таблиц» нет: любая таблица уже лежит в озере и готова к анализу с консистентностью на момент запроса.
В отличие от HTAP (попыток сделать один движок, умеющий всё), который страдает от урезанного функционала, отсутствия экосистемы и конкуренции за ресурсы, LTAP объединяет данные на уровне хранения, оставляя лучший инструмент для каждой задачи: Postgres для транзакций и Lakehouse для аналитики, с полной изоляцией ресурсов.