MotherDuck не собирается заводить собственный форк DuckDB, хотя у компании для этого, казалось бы, все карты на руках: коммерческий продукт, облачная платформа и, по словам команды, крупнейший в мире парк инсталляций на базе DuckDB. Для русскоязычной IT-аудитории это важный сигнал: MotherDuck и DuckDB пока развиваются не по сценарию «open source для витрины, закрытый форк для денег», а по более редкой модели, где коммерческий игрок старается не разорвать совместимость с ядром.
Об этом на полях MCP Dev Summit North America в Нью-Йорке рассказал The New Stack AI Lead компании Till Döhmen. Его тезис звучит предельно прагматично: если MotherDuck упирается в ограничения движка, команда не спешит отпиливать себе отдельную ветку, а обсуждает изменения с DuckDB Labs и пытается протолкнуть нужные улучшения в основной проект. Логика понятная: если компания уже эксплуатирует DuckDB в продакшене на масштабе, который не снился большинству команд, ее обратная связь для maintainers стоит дорого. А поддержка собственного форка, наоборот, быстро превращается в дорогую привычку.
Собственно, в этом и был самый интересный момент разговора. The New Stack прямо задал вопрос, который обычно вежливо обходят: если MotherDuck знает, где у DuckDB пределы, почему бы не оставить эти знания себе и не сделать продукт более отличающимся от открытой базы? Ответ был довольно жесткий: форк компании не нужен. Вместо этого MotherDuck использует расширяемость DuckDB, в частности возможности вокруг планировщика запросов, чтобы дорабатывать свою платформу без разрыва с апстримом. А если речь идет уже не о точечной адаптации, а о действительно базовых изменениях в ядре, их стараются обсуждать с теми, кто ведет основной проект.
Для понимания контекста это важнее, чем кажется. DuckDB давно живет в головах разработчиков как «SQLite для аналитики»: легкий in-process движок, который удобно запускать локально, рядом с Python, ноутбуком или скриптом, не поднимая отдельный сервер. Именно за это его любят data engineers, аналитики и команды, которым не хочется тащить в маленький проект весь зоопарк из warehouse, orchestrator и отдельной инфраструктуры. Но у такого удобства есть оборотная сторона: локальный DuckDB отлично чувствует себя в режиме «один инженер, один файл», а вот в организации быстро начинаются вопросы про совместную работу, обмен файлами, доступы, шаринг и повторяемые рабочие процессы.
MotherDuck как раз и строит бизнес на том, чтобы превратить этот одиночный сценарий в «многопользовательский DuckDB». На официальных страницах компания прямо описывает себя как облачный слой поверх DuckDB, созданный в партнерстве с DuckDB Labs. Идея старая как SaaS, но исполнение здесь аккуратное: не заменить исходный продукт, а дотянуть его до совместной работы в облаке, серверлесс-модели и корпоративных сценариев. По словам Döhmen, речь идет не только о внутренних BI-задачах, но и о внешних пользовательских кейсах, где нужен data backend на базе тех же примитивов.
Отдельный сюжет здесь связан с MCP. В заметке The New Stack Döhmen говорит, что в MotherDuck по мере движения в сторону Model Context Protocol даже нетехнические сотрудники получили возможность работать со своими данными через агентов, а не через заранее собранные дашборды. Это уже не разговор про красивую демку. У MotherDuck есть официальный MCP-сервер с открытым кодом: он умеет подключаться к локальным DuckDB-файлам, к облачным базам MotherDuck и к данным в S3, а также поддерживает режимы только для чтения и короткоживущие соединения. Последняя деталь особенно показательна: инструмент явно проектировали под реальный workflow, где рядом живут dbt, IDE, агент и локальная база, и никто не хочет ловить блокировки из-за «умного помощника», который забыл закрыть коннект.
На рынке это выглядит как аккуратная контратака против мантры «все должно бесконечно масштабироваться». Döhmen в другом интервью с того же саммита говорил, что индустрия слишком любит истории про гигантские кластеры и слишком редко обсуждает сценарии небольших команд, которым не нужен warehouse размером с Uber. MotherDuck продает как раз эту мысль: не переплачивать за инфраструктуру, которую вы, возможно, никогда не загрузите. Упор на serverless здесь не маркетинговый декор, а часть продуктовой философии: платить за реально использованное время вычислений и за фактическое хранение, а не резервировать мощность «на всякий случай».
Для разработчиков и продуктовых команд из России и СНГ в этой истории есть вполне прикладной вывод. Когда коммерческая компания не уходит в собственный форк, экосистема обычно выигрывает по трем направлениям сразу. Первое: ниже риск несовместимости между open-source-инструментом и облачным сервисом. Второе: меньше шанс, что полезные улучшения застрянут в закрытом продукте и не доедут до сообщества. Третье: проще строить стек вокруг одного движка, не опасаясь, что через год придется выбирать между «чистым DuckDB» и «тем самым DuckDB, но от вендора и уже не совсем DuckDB». Для CTO и фаундеров это еще и вопрос экономики: поддержка форка выглядит круто в презентации, но почти всегда заканчивается налогом на каждое обновление, тесты и найм людей, которые будут разгребать расхождение с апстримом.
При этом идеализировать картину не стоит. Коммерческое напряжение никуда не делось: MotherDuck монетизирует то, что построено на популярном open-source-ядре, а DuckDB Labs и фонд DuckDB отвечают за развитие самого проекта. Пока этот танец работает, выигрывают все: open source получает продакшен-обратную связь, а вендор получает продукт без затрат на содержание отдельной кодовой вселенной. Но чем сильнее вокруг данных и агентов будет раскручиваться новый рынок, тем интереснее станет вопрос, где проходит граница между «партнерством» и фактическим управлением повесткой open source. Исходный разговор с Döhmen можно посмотреть в материале .