Hacker News Digest

Вышел DuckDB 2.0.0 с длительной поддержкой (LTS), кодовое имя «Cinnamon Teal» — в честь коричной чирки, красновато-бурой утки из западных Америк. Это крупнейший по числу функций релиз: почти 20 000 коммитов с версии 1.5. В отличие от 1.0, делавшей ставку на стабильность и обратную совместимость, 2.0 — прежде всего функциональный выпуск. В него вошли отточенная версия протокола Quack, асинхронный ввод-вывод, полноценный тип VARIANT, режим агента, триггеры и расширяемый парсер SQL.

DuckDB изначально была встраиваемой базой, но теперь её можно запускать в классической схеме «клиент — сервер»: расширение quack реализует родной протокол, а новый оператор CONNECT позволяет подключать удалённую базу и переключаться на неё одной командой. Поддержка 2.0 продлится как минимум до октября 2027 года; предыдущая LTS 1.4 поддерживается до конца ноября 2026-го, а срок поддержки 1.5 продлили до марта 2027-го, фактически тоже сделав её LTS. Сборка «amalgamation» (весь исходный код в одном заголовочном и одном исходном файле) объявлена устаревшей, а платформа osx_amd64 постепенно выводится из числа полностью поддерживаемых — в 2.1 её поддержка прекратится.

Обсуждение дополняет статью кейсами использования DuckDB как замены Spark, инструмента для анализа логов, федеративного движка для объединения разрозненных источников (включая таблицы) и основы для браузерных приложений. Основные тезисы: — Версия 2.0 значительно ускорила работу на многоядерных системах (EC2): @RobinL отмечает утилизацию до 128–192 vCPU (против 64 ранее), что позволило обработать 1 млрд записей за 10 минут. — Для сжатия логов @jiggawatts за два часа перевел 7 ТБ NDJSON из Azure в Parquet, сократив объем до 2,5%. — Асинхронный I/O при работе с удаленными данными (S3/HTTP) и паттернами glob (например, `*.parquet`) предотвращает блокировку рабочих потоков (@jtbaker, @skeeter2020). — DuckDB позволяет обходить проблемы row-based security в централизованных хранилищах, предоставляя пользователям локальные копии данных (@skeeter2020). — С помощью duckdb-wasm и оптимизации раскладки данных в браузер можно передавать от 2–3 млн строк (16–20 МБ) до 1 ГБ через HTTP range queries (@gopalv). — Клиент-серверная архитектура позволяет создавать легковесные сервисы с горизонтальным масштабированием или масштабированием до нуля через Cloud Run (@paoliniluis, @jtbaker, @bambax). — Для интеграции с инструментами анализа (например, Metabase) рекомендуются расширения Quack или поддержка Postgres wire (@nicoritschel, @paoliniluis). — При использовании в качестве основного сервера БД с транзакциями рекомендуется ограничиться одним записью (single writer) (@netcraft, @throwawaythekey).

DuckLabs, команда разработчиков DuckDB, DuckLake и Quack, присоединяется к AWS, сохраняя при этом открытый характер своих проектов. Команда останется в Амстердаме и продолжит работу над технологиями, которые уже достигли более миллиона ежедневных загрузок и стали фундаментом для аналитики, образования и промышленных систем по всему миру. Основная мотивация перехода — преодоление ограничений текущей модели: небольшая команда больше не могла масштабировать поддержку и инфраструктуру в соответствии с растущим спросом, рискуя стать узким местом для проекта и его сообщества.

Сотрудничество с AWS уже велось более года, включая интеграцию с Amazon S3 Tables, и показало синергетический потенциал: техническая экспертиза DuckLabs сочетается с инфраструктурой, охватом и ресурсами AWS для вывода Duck Stack на новый уровень. Критически важно, что все открытые компоненты — DuckDB, DuckLake, Quack — останутся свободно доступными под лицензией MIT, а их stewardship продолжит некоммерческая DuckDB Foundation. Основатели подчеркивают, что успех проекта принадлежит глобальному сообществу, и видят в этом шаге возможность расширить влияние DuckDB, не жертвуя его открытостью и технической целостностью.

Тред в целом принимает переход DuckLabs в AWS, но скептичен к AWS как долгосрочному хранителю OSS после реорганизаций и ухудшающейся внутренней культуры, на фоне которой сложно удержать талант. Ключевая поправка: IP DuckDB остаётся у некоммерческой DuckDB Foundation, а DuckLabs станет дочерней компанией AWS — AWS купил команду и сервисный бизнес, а не код. Спор о пригодности AWS как дома для DuckDB: часть участников (@hobofan, @akshay_akula, @cmgs8) считает, что AWS «закапывает» технически интересные проекты при реорганизациях; другие (@georgewfraser, @hckshr) возражают — AWS технологически нейтрален, а сервисное подразделение подходит для коммерческой поддержки DuckLabs. Сами авторы опасались масштабировать коммерческую часть, чтобы не отвлекаться от OSS, поэтому покупка именно сервисного бизнеса выглядит логично. Ожидаются managed-интеграции с S3/Athena и конкуренция со Snowflake/Databricks; @karakanb видит шанс на более лёгкую альтернативу Athena через DuckDB поверх данных в S3. Сравнение с Redshift (ParAccel) и Athena (форк Trino/Presto) указывает на стратегию отвоёвывания доли у Snowflake и Databricks в эпоху AI. Допускается, что сделка могла быть упреждающей — AWS готовил managed-клон DuckDB, и команда предпочла продаться (@fidotron). Практический контекст: DuckDB широко используется как parquet-просмотрщик и для локальной разработки (@ferguess_k), а DuckDB и DuckLake уже применяются как расширяемый фреймворк для исследовательских пайплайнов (@willbeddow, Krea). Отмечены болезни процесса контрибуции — CI на простой bugfix может занимать ~5 часов (@adsharma), что объясняет интерес к source distributions вроде Haybarn. Как «fork-ready» альтернативы обсуждаются Apache DataFusion (библиотека с Rust/Python/Java-биндингами, по опыту @tormeh лучше интегрируется в Rust-приложения, чем DuckDB) и гео-фокусный SedonaDB под Apache 2.0 (@adeptima). Опасения по «Big Tech ломает OSS» (@pepperoni_pizza, @dtnm, @log101): переписывание на Rust с AI-агентами, дрейф фокуса команды на AWS-продукты (@ganeshsivakumar), потеря OSS-импульса и развитие DuckDB как куска product suite против Databricks, а не как независимого проекта. Многие (@sakesun, @cmgs8, @srameshc) уважают лидеров проекта лично, но тревожатся за будущее из-за бренда AWS и сигналов ухода топ-таланта, замеченных в LinkedIn (@cmgs8).

DuckDB v2.0, codenamed «Cyanoptera», выходит этим осенью и представляет набор кардинальных изменений: серверный режим через расширение quack и оператор CONNECT, новый SQL‑парсер, переработанную СУБД‑структуру, асинхронный ввод‑вывод и тип VARIANT. Серверный режим позволяет любой процессу DuckDB обслуживать базы данных по сети, а клиентские запросы можно отправлять напрямую на удалённый PostgreSQL или MySQL без копирования данных. Кроме того, в v2.0 введены триггеры, более строгая типизация и поддержка транзакций в многопользовательском режиме, что делает DuckDB конкурентоспособным для аналитических и даже транзакционных нагрузок.

Ключевые нововведения: серверный режим (quack + CONNECT), новый тип VARIANT для гибкого хранения схем, асинхронный I/O ускоряющий запросы, новая хранилище‑формат с улучшенной компрессией, а также новый C‑API и небольшие, но важные ломающие изменения (переход на lambda‑синтаксис). В статье также упоминается создание DuckDB Foundation Advisory Board, который будет влиять на дальнейшее развитие проекта. Эти изменения формируют фундамент для «года DuckDB как сервера» и открывают путь к масштабным распределённым решениям.

DuckDB v2.0 трансформируется из локального аналитического процессора в основу облачной аналитической инфраструктуры, что подтверждено использованием в продакшене: многотенантные системы с данными 5–150 ГБ на тенанта, обработка миллионов Parquet-файлов, замена серверных решений. Он превосходит PostgreSQL и MariaDB в OLAP-задачах благодаря колоночному хранению и встроенному процессу, но уступает в многопользовательской конкурентности без Quack. Поддерживает обработку данных, превышающих ОЗУ, на потребительском оборудовании, снижая требования к инфраструктуре. Асинхронный ввод-вывод в v2.0 критически важен для масштабной работы с Parquet и обеспечивает значительный прирост производительности. WASM-сборка весит ~10 МБ, пригодна для браузера; расширения не увеличивают размер бинарников существенно. Заменяет сложные ETL-пайплайны, позволяя объединять запросы к CSV, Parquet и базам данных в одном SQL-интерфейсе. Стандартная практика — анализ лог-файлов (например, Nginx access.log) на диске. Рекомендации: - Использовать Arc для ускорения сканирования через pruning при работе с Parquet. - Для расширений применять официальный шаблон extension-template. - Ручная настройка memory_limit необходима для предотвращения убийства OOM-killerом. - При аналитике в браузере кастомизировать Emscripten-сборку — она оптимизирована, но требует настройки. - Документировать новый PEG-парсер — его детали критичны для совместимости. Quack (серверный режим) и CONNECT к PostgreSQL делают DuckDB гибридным инструментом, интегрируемым с OLTP-системами. Споры: - Некоторые считают DuckDB неподходящим для распределённой обработки против AWS Athena с Trino, но Quack и DuckLake меняют эту динамику. - Одни выражают разочарование, что DuckDB не переписан на Zig, другие не видят в этом проблемы.