В прошлом году Databricks купил Neon. Основатели Neon: • Никита Шамгунов - CEO и идейный вдохновитель Россиянин, PhD по Computer Science из Санкт-Петербурга • Хейкки Линнакангас - Co-founder, Postgres-хакер Финн, один из самых известных core committer'ов PostgreSQL с 20+ летним стажем. • Стас Кельвич - Co-founder, инженер. Изучал физику, затем пришёл в разработку — работал в Яндексе в команде баз данных. Команда собралась вокруг одной идеи: "что если сделать для Postgres то же, что Amazon Aurora сделала для MySQL/Postgres, но open-source и по-настоящему serverless?" Amazon Aurora это serverless Postgres, но это как бы vendor lock. У Neon было три основных этапа/фичи: 1️⃣Разделение слоев давало serverless-поведение: scale-to-zero, оплата только за реальное использование, "бездонное" хранилище. 2️⃣Разделение compute и storage открыло неожиданную суперспособность - branching базы данных через copy-on-write. Создать полную копию базы с данными и схемой стало бесплатным по времени и почти бесплатным по стоимости. Кстати Snowflake zero-copy cloning имеет похожую идею copy-on-write - клон/ветка не копирует данные физически, а создаёт метаданные-указатели на те же блоки хранилища. Новые данные записываются только при изменениях. Оба мгновенные и почти бесплатные по хранилищу. Только у Neon каждая ветка это свой изолированный Postgres. Благодаря этому у каждой ветки свой compute и не влияет на продакшн базу данных. 3️⃣Neon обнаружил, что 80% баз на их платформе создаются кодом, а не людьми. AI-агенты и платформы вроде Replit Agent стали создавать тысячи эфемерных баз на лету - под каждого пользователя, под каждый эксперимент. Один инженер в Retool управлял через Neon API 300,000 Postgres-инстансов. Для Databricks это решение понравилось, ведь они уже работаю с AI агентами, каждый агент получает свою изолированную базу данных, и сама идея Zero ETL не нова, и Neon позволяет использовать OLTP workloads и хранить данные сразу в Databricks, ведь Neon хранит данные в облачном object storage (S3/ADLS/GCS), то есть буквально в том же хранилище, что и lakehouse. И вот Databricks закончил интеграцию и назвал продукт/фичу - Lakebase. Это Postgres версии 16/17. Так же Databricks приобрел Mooncake для лучшей интеграции Postgres с Lakehouse. Mooncake Labs - это маленький стартап (основан в 2024 году), который сделал одну очень конкретную вещь: ⁠pg_mooncake — Postgres-расширение, которое добавляет колоночное хранилище прямо внутрь Postgres, сохраняя данные в формате Apache Iceberg/Delta Lake в object storage. Под капотом происходит следующее: • Данные хранятся не в Postgres heap (row-формат), а в Parquet-файлах в S3 в формате Iceberg • Аналитические запросы выполняются через DuckDB (встроен в расширение) - векторизованный движок, заточенный под колоночное чтение Neon дал serverless Postgres compute, но данные в нём хранились в Postgres-формате — отдельно от lakehouse. Чтобы аналитические движки (Spark, Databricks SQL) могли их читать, нужно было либо копировать данные через ETL, либо держать два источника правды. Mooncake закрыл этот gap: вместо того чтобы копировать данные из Postgres в lakehouse, он делает Iceberg основным хранилищем. Postgres пишет сразу в Iceberg/Parquet в S3 - и тот же файл без какого-либо ETL читают и приложения через Postgres, и аналитика через Spark. Есть еще Synced Tables - это отдельный, более старый механизм для обратного направления: когда нужно "опустить" уже готовые аналитические данные из Unity Catalog в Lakebase, чтобы приложение могло читать их с низкой латентностью (< 10 мс) (Reverse ETL). Здесь дублирование данных неизбежно — потому что аналитический Parquet нужно переложить в row-формат Postgres для быстрых point-lookup запросов. PS Работаю часто с Databricks, пока реальных кейсов на Lakebase Postgres не видел =/