DuckDB v2.0: як embedded database готується стати повноцінною клієнт-серверною аналітичною базою даних

Коротко: DuckDB v2.0 “Cyanoptera” — майбутня велика версія DuckDB, яка додає стабільний клієнт-серверний режим через Quack, оператор CONNECT, повноцінну підтримку VARIANT, тригери, асинхронний I/O, новий SQL-парсер і новий формат зберігання за замовчуванням. Станом на вересень 2026 року v2.0 ще не вийшла: доступні alpha-збірки, а стабільний реліз запланований на другу половину жовтня 2026 року.

Вступ

DuckDB з’явилася як in-process аналітична СУБД: рушій працює прямо всередині застосунку без окремого сервера. Саме ця простота зробила її популярною серед аналітиків, data engineers і розробників. DuckDB v2.0 розширює цю модель: embedded-режим нікуди не зникає, але поруч із ним з’являється зрілий клієнт-серверний сценарій через Quack.

Водночас важливо не поспішати називати v2.0 завершеним релізом. Команда DuckDB 2 вересня 2026 року відгалузила гілку v2.0-cyanoptera, оголосила feature freeze і перейшла до тестування та bug fixing. Фінальний реліз очікується у другій половині жовтня.

У цій статті розберемо, що саме готує DuckDB v2.0, як працюють Quack і CONNECT, чим VARIANT відрізняється від JSON, навіщо DuckDB тригери і де клієнт-серверний DuckDB може бути корисним поруч із PostgreSQL та іншими системами.

Чому DuckDB v2.0 — велика архітектурна зміна для проєкту?

DuckDB традиційно описують як «SQLite для аналітики»: embedded database без обов’язкового серверного процесу, мережевих портів і складного адміністрування. Але сама DuckDB від початку підтримувала транзакції, multiple connections у межах процесу, MVCC та ізоляцію транзакцій.

Версія 2.0 не відмовляється від embedded-підходу. Навпаки, вона додає ще один спосіб використання тієї самої СУБД — як довготривалого сервера, до якого можуть підключатися інші процеси по мережі.

Ключові зміни, які команда анонсувала для v2.0:

• Quack як стабільний клієнт-серверний протокол;
• новий оператор CONNECT для маршрутизації сесії на віддалену базу;
• VARIANT як first-class тип для напівструктурованих даних;
• BEFORE/AFTER triggers, row-level і statement-level triggers;
• новий PEG-based SQL parser;
• новий default storage format;
• reworked C API;
• асинхронний I/O по всьому рушію;
• невеликий набір цілеспрямованих breaking changes.

Реліз побудований на більш ніж 10 000 комітах після DuckDB v1.5, що вийшла у березні 2026 року.

Чим embedded database відрізняється від клієнт-серверної архітектури?

Embedded database працює в тому самому процесі, що й застосунок. Наприклад, Python-код завантажує DuckDB як бібліотеку і виконує SQL без окремого серверного процесу.

Важливе уточнення: embedded не означає «тільки одне з’єднання». DuckDB давно підтримує кілька connections і транзакційну роботу. Головне обмеження embedded-моделі інше: база не виступає самостійним мережевим сервісом для клієнтів на інших процесах або машинах.

Клієнт-серверний режим вирішує саме це. DuckDB-процес можна підняти як сервер, а інші клієнти підключаються через Quack і працюють із віддаленою базою. Це відкриває multi-client і long-running deployment-сценарії, яких раніше не було в типовому DuckDB workflow.

Як працює DuckDB server: Quack та CONNECT

Quack — HTTP-based remote protocol, який дозволяє одному DuckDB-процесу обслуговувати інші DuckDB-процеси по мережі. Quack уже доступний у DuckDB v1.5.3 як core extension, але станом на вересень 2026 року все ще має beta/experimental status. У DuckDB v2.0 команда планує перевести його в stable.

Базовий приклад із preview v2.0 виглядає так:

CALL quack_serve(
    token = 'my_token'
);

CALL quack_serve(
    token = 'my_token'
);

На клієнтській стороні:

ATTACH 'quack:server.example.com'
    AS qk (TOKEN 'my_token');

CONNECT qk;

SELECT count(*) FROM events;

DISCONNECT;

ATTACH 'quack:server.example.com'
    AS qk (TOKEN 'my_token');

CONNECT qk;

SELECT count(*) FROM events;

DISCONNECT;

Оператор CONNECT змінює контекст поточної сесії: запити всередині цього режиму виконуються на віддаленій базі, а результати повертаються клієнту. CONNECT не обмежується Quack. У preview DuckDB показала remote pushdown для PostgreSQL і MySQL:

CONNECT 'postgres://localhost/mydb';

SELECT count(*) FROM orders;

DISCONNECT;

CONNECT 'postgres://localhost/mydb';

SELECT count(*) FROM orders;

DISCONNECT;

Ідея полягає в тому, що SQL передається на віддалену систему, а не обов’язково завантажує цілі таблиці в локальний DuckDB для обробки. Проте оскільки v2.0 поки alpha, синтаксис, protocol details та implementation details до стабільного релізу ще можуть змінитися.

DuckDB server vs PostgreSQL: чи стає DuckDB заміною традиційній СУБД?

Клієнт-серверний режим робить порівняння з PostgreSQL природнішим, але ці системи все ще оптимізовані під різні пріоритети.

DuckDB може бути дуже конкурентною на аналітичних workload-ах і тепер отримує мережевий режим, але це не означає, що вона автоматично замінює PostgreSQL у системах із великою кількістю дрібних одночасних write-транзакцій.

Що таке VARIANT і чим він відрізняється від JSON?

VARIANT з’явився ще в DuckDB v1.5. Це тип для semi-structured data, який, на відміну від JSON, не зберігається як текст. Кожне значення має власну type information, а DuckDB може «shred» спільну структуру даних для кращого compression і швидшого виконання запитів.

У v2.0 VARIANT стає first-class citizen у повному pipeline: shredded execution зі storage, extraction pushdown у scans, читання і запис shredded VARIANT у Parquet та набір variant_* functions.

CREATE TABLE events (payload VARIANT);

INSERT INTO events
VALUES ('{"user": {"id": 42, "tags": ["a", "b"]}}'::JSON::VARIANT);

SELECT variant_type(payload), variant_keys(payload)
FROM events;

SELECT *
FROM events
WHERE variant_contains(
    payload,
    {'user': {'id': 42}}::VARIANT
);

CREATE TABLE events (payload VARIANT);

INSERT INTO events
VALUES ('{"user": {"id": 42, "tags": ["a", "b"]}}'::JSON::VARIANT);

SELECT variant_type(payload), variant_keys(payload)
FROM events;

SELECT *
FROM events
WHERE variant_contains(
    payload,
    {'user': {'id': 42}}::VARIANT
);

Команда DuckDB також заявила про довгостроковий план зробити звичайний JSON поверх VARIANT, але це не обіцянка саме релізу v2.0 — у preview прямо зазначено, що це, ймовірно, станеться пізніше.

Навіщо DuckDB тригери?

DuckDB v2.0 додає повноцінну підтримку triggers: BEFORE і AFTER, FOR EACH ROW і FOR EACH STATEMENT, transition tables через REFERENCING OLD/NEW TABLE, кілька triggers на одну подію, RETURNING і DROP TRIGGER.

Офіційний приклад audit-table:

CREATE TABLE target (id INTEGER, val INTEGER);
CREATE TABLE audit (id INTEGER, old_val INTEGER, new_val INTEGER);

CREATE TRIGGER trg_audit AFTER UPDATE ON target
REFERENCING OLD TABLE AS o NEW TABLE AS n
FOR EACH STATEMENT
    INSERT INTO audit
    SELECT n.id, o.val, n.val
    FROM o
    JOIN n ON o.id = n.id;

INSERT INTO target VALUES (1, 10), (2, 20);
UPDATE target SET val = val * 10 WHERE id <= 2;

SELECT * FROM audit;

CREATE TABLE target (id INTEGER, val INTEGER);
CREATE TABLE audit (id INTEGER, old_val INTEGER, new_val INTEGER);

CREATE TRIGGER trg_audit AFTER UPDATE ON target
REFERENCING OLD TABLE AS o NEW TABLE AS n
FOR EACH STATEMENT
    INSERT INTO audit
    SELECT n.id, o.val, n.val
    FROM o
    JOIN n ON o.id = n.id;

INSERT INTO target VALUES (1, 10), (2, 20);
UPDATE target SET val = val * 10 WHERE id <= 2;

SELECT * FROM audit;

Тригери особливо логічні для long-running server workloads, де база живе довше за один notebook або ETL job і має реагувати на зміни даних усередині самої СУБД.

Які нові SQL-можливості з’являються у v2.0?

Preview DuckDB v2.0 містить багато SQL-level доповнень. Найпомітніші з них:

• NEAREST joins для top-k similarity search:

SELECT q.user_id, t.product_id
FROM users q
INNER JOIN products t APPROX NEAREST 2
BY SIMILARITY array_cosine_similarity(
    q.embedding,
    t.embedding
);

SELECT q.user_id, t.product_id
FROM users q
INNER JOIN products t APPROX NEAREST 2
BY SIMILARITY array_cosine_similarity(
    q.embedding,
    t.embedding
);

• DML усередині CTE:

WITH moved AS MATERIALIZED (
    DELETE FROM staging RETURNING *
)
INSERT INTO archive
SELECT * FROM moved;

WITH moved AS MATERIALIZED (
    DELETE FROM staging RETURNING *
)
INSERT INTO archive
SELECT * FROM moved;

• nested schemas;
• змінні через синтаксис $x;
• json_set, json_insert, json_replace та json_remove;
• recursive CTE з USING KEY aggregation;
• SQL-standard FETCH FIRST … ROWS ONLY;
• OVERLAY();
• UNNEST у GROUP BY;
• чіткіша семантика MERGE та UPDATE … FROM для multi-match cases.

Що змінюється під капотом?

DuckDB v2.0 вводить asynchronous I/O по всьому рушію. Особливо важливо це для object storage на кшталт S3: I/O layer може масштабуватися незалежно від query processing, що збільшує паралелізм під час remote reads.

Окремо DuckDB повністю замінює старий PostgreSQL-derived parser на PEG-based parser. Новий parser має бути простішим для розвитку і допускає runtime extensions.

Також з’являється новий default storage format, reworked C API та невеликий набір навмисних breaking changes. Сам факт major-version bump означає, що команди перед production-upgrade мають прогнати compatibility tests на власних workloads.

Де DuckDB v2.0 вписується в сучасний data stack?

Найцікавіше у v2.0 — не те, що DuckDB «перестає бути embedded». Вона не перестає. Натомість одна технологія тепер покриває ширший спектр сценаріїв: від локального ноутбука і Python-процесу до networked multi-client deployment.

Це може бути зручно для команд, яким потрібна проста аналітична база без переходу одразу до важчого кластерного стеку. Але server-mode DuckDB ще молодий, тому для критичних production-систем варто оцінювати зрілість tooling, HA/operations requirements, concurrency profile та security окремо.

Станом на вересень 2026 року найкращий спосіб познайомитися з v2.0 — тестувати alpha-збірки на некритичних workloads і перевіряти compatibility перед стабільним релізом.

FAQ: питання про DuckDB v2.0

Питання: Що таке DuckDB v2.0?

Відповідь: DuckDB v2.0 “Cyanoptera” — майбутній major release DuckDB із client-server режимом через Quack, triggers, first-class VARIANT, asynchronous I/O, новим parser і storage format. Станом на вересень 2026 року реліз ще перебуває на alpha-стадії.

Питання: Коли вийде DuckDB v2.0?

Відповідь: Команда DuckDB 2 вересня оголосила feature freeze і прогнозує стабільний реліз у другій половині жовтня 2026 року.

Питання: Як зараз протестувати client-server DuckDB?

Відповідь: Quack уже доступний у v1.5.3 як core extension у beta/experimental state. Для v2.0 також доступні alpha builds, де можна тестувати нові можливості до стабільного релізу.

Питання: Чи замінює DuckDB v2.0 PostgreSQL?

Відповідь: Ні. DuckDB розширюється в server-сценарії, але її основний фокус залишається аналітичним. PostgreSQL має значно зрілішу екосистему для high-concurrency OLTP.

Питання: Чи залишиться embedded mode?

Відповідь: Так. Client-server режим — додаткова можливість. Звичайний in-process DuckDB залишається базовим сценарієм використання.

Питання: Чи можна вже використовувати v2.0 у критичному production?

Відповідь: До стабільного релізу це alpha software. Для production краще залишатися на стабільній гілці або проводити v2.0 testing окремо, поки команда не випустить фінальний реліз.

Висновок

DuckDB v2.0 — це не відмова від embedded-філософії, а розширення її меж. Quack і CONNECT додають мережевий client-server сценарій, VARIANT робить semi-structured data повноцінною частиною рушія, triggers наближають DuckDB до звичних server DBMS workflow, а asynchronous I/O, новий parser і storage format перебудовують фундамент системи.