Источник
Wikipedia: DuckDB
История проекта DuckDB и позиционирование как in-process OLAP СУБД.
Официальный сайт
DuckDB
Официальная документация, релизы, SQL-функциональность и интеграции с экосистемой данных.
DuckDB - in-process аналитическая СУБД с SQL-интерфейсом и vectorized execution. В системном дизайне её часто используют как embedded OLAP слой для локальной аналитики, ELT и работы с файлами data lake (Parquet/CSV), когда не нужен отдельный серверный кластер.
История и контекст
Публичный старт проекта
DuckDB появляется как open-source in-process OLAP движок для аналитики внутри приложения и ноутбуков.
Подготовка к 1.0
Линия 0.10.x расширяет SQL-возможности и performance-профиль перед стабильной 1.x веткой.
Стабильный мажорный релиз
Проект фиксирует стабильную 1.0 линию с фокусом на совместимость формата хранения и production-использование.
Развитие 1.x ветки
Продолжаются улучшения оптимизатора, SQL-функций и интеграций с аналитической экосистемой.
Стабилизация LTS-линии
LTS-ветка усиливает предсказуемость апгрейдов и поддержку production-сценариев с длинным циклом релизов.
Ключевые архитектурные элементы
In-process архитектура
DuckDB работает как библиотека в процессе приложения: без отдельного DB-сервера и сетевого hop между кодом и движком.
Vectorized SQL execution
Запросы выполняются батчами в pipeline-операторах, что ускоряет scan-heavy OLAP workload на одном узле.
Columnar storage + open formats
Колонночное хранение и прямой доступ к Parquet/CSV/Arrow делают DuckDB удобным SQL-слоем для data lake файлов.
ACID и concurrency ограничения
Есть ACID/MVCC/WAL, но модель конкурентной записи ориентирована на один writer process для файла БД.
Execution и storage модель
Ниже интерактивный разбор модели DuckDB: in-process deployment, vectorized engine, storage layout, транзакционность и ограничения по конкурентной записи.
Execution и storage модель DuckDB
DuckDB совмещает in-process deployment, vectorized execution и колонночное хранение, поэтому закрывает аналитические сценарии без отдельного серверного кластера.
Почему DuckDB — это отдельный класс аналитической СУБД
- Движок работает внутри процесса приложения, что снижает operational overhead для аналитики.
- Vectorized execution и columnar storage оптимизируют scan-heavy OLAP запросы.
- Есть ACID транзакции, WAL и checkpoint, но concurrency-модель ориентирована на один writer process.
- DuckDB нативно работает с Parquet/CSV/Arrow и подходит для embedded ELT/аналитики.
In-process deployment
DuckDB запускается как библиотека внутри приложения (Python/R/CLI/BI), без отдельного DB server процесса.
Ключевые элементы
Типичные сценарии
- Notebook analytics
- Local BI
- Application-side data processing
Пример
import duckdb
con = duckdb.connect('warehouse.duckdb')High-Level Architecture
Схема показывает high-level контур DuckDB: клиентский embedding, SQL/optimizer слой, vectorized execution pipeline, storage subsystem и экосистемные интеграции.
System view
Performance profile
Operational trade-offs
Read / Write Path через компоненты
Диаграмма объединяет write и read path: от SQL-команды клиента через optimizer и vectorized execution до записи в storage или возврата аналитического результата.
Read/Write Path Explorer
Интерактивный разбор прохождения DuckDB-команд через SQL planner, vectorized execution и storage слой.
Write path
- DuckDB оптимизирован под bulk-запись (`COPY`, батчевый `INSERT`, `CTAS`) в одном процессе.
- План записи проходит optimizer и исполняется vectorized операторами батчами.
- Транзакции ACID + WAL/`CHECKPOINT` обеспечивают durability в persistent режиме.
- Схемы с индексами/constraints повышают integrity, но могут замедлить массовую загрузку.
Когда выбирать DuckDB
Хорошо подходит
- Embedded аналитика в приложении, notebook и локальных BI-инструментах.
- ELT/EDA-пайплайны по Parquet/CSV/JSON без подъёма отдельного кластера.
- Feature engineering и ad-hoc аналитика рядом с Python/Pandas/Polars.
- Оффлайн и edge-сценарии, где важны простота доставки и минимальный operational overhead.
Стоит избегать
- Многопользовательский OLTP-сервис с интенсивными concurrent writes из разных процессов/нод.
- Требование к распределённому кластеру с автоматическим failover и горизонтальным масштабированием хранилища.
- Системы с высокой потребностью в row-level locking и длинных конкурентных транзакциях.
- Сценарии, где нужен постоянный удалённый DB endpoint для множества независимых сервисов.
Практика: DDL и DML
Ниже примеры SQL-операций в DuckDB: DDL для схемы/индексов и DML для ingest, трансформаций и аналитических запросов.
Примеры DDL и DML в DuckDB
DDL описывает схему/индексы, DML управляет загрузкой и аналитическими запросами.
DuckDB использует классический SQL DDL: таблицы, constraints, индексы, схемы и ATTACH для работы с несколькими БД-файлами.
Создание аналитических таблиц и ограничений
CREATE TABLEDDL задаёт структуру и базовые правила целостности данных.
CREATE TABLE users (
user_id BIGINT PRIMARY KEY,
plan VARCHAR,
created_at TIMESTAMP
);
CREATE TABLE events (
event_id BIGINT,
user_id BIGINT,
event_type VARCHAR,
event_ts TIMESTAMP,
payload JSON,
FOREIGN KEY (user_id) REFERENCES users(user_id)
);Индекс для селективных фильтров
CREATE INDEXИндексы в DuckDB полезны для точечных/селективных условий, но не всегда нужны для scan-heavy аналитики.
CREATE INDEX idx_events_user_ts
ON events (user_id, event_ts);ATTACH и создание витрины в отдельной схеме
ATTACH + CREATE SCHEMA/TABLEМожно держать raw и mart-слои в отдельных attached БД и схемах.
ATTACH 'warehouse.duckdb' AS wh;
USE wh;
CREATE SCHEMA IF NOT EXISTS mart;
CREATE TABLE mart.daily_events AS
SELECT DATE(event_ts) AS dt, event_type, count(*) AS cnt
FROM events
GROUP BY 1, 2;