DuckDB вместо ноутбука с pandas
Привычка тянуть данные в pandas сидит крепко: read_csv, пара
merge, groupby — и график готов. Пока файл на сто мегабайт,
всё честно работает. На гигабайте ноутбук начинает думать, на трёх — падает по памяти,
и дальше начинается ритуал с чанками.
Последний месяц вместо этого беру DuckDB. Ставится одной строкой, живёт в процессе, отдельного сервера не требует. И читает файлы прямо с диска, не загружая их целиком.
Как это выглядит
Вместо чтения всего файла — запрос к нему:
import duckdb
duckdb.sql("""
SELECT region, date_trunc('month', ts) AS m, sum(amount) AS total
FROM 'exports/*.parquet'
WHERE ts >= '2026-01-01'
GROUP BY 1, 2
ORDER BY 2, 1
""").df()
Звёздочка в пути работает как glob — можно скормить директорию из сотни файлов,
и это по-прежнему один запрос. Колоночный формат читается лениво: если в
SELECT три поля из сорока, остальные с диска даже не поднимутся.
Что реально изменилось
Замерил на своей папке выгрузок — 4.2 ГБ в parquet, 38 файлов. Одна и та же агрегация:
| Способ | Время | Пик памяти |
|---|---|---|
| pandas, чтение целиком | не дождался | OOM на 16 ГБ |
| pandas по чанкам | 4 мин 10 с | 2.1 ГБ |
| DuckDB | 11 с | 780 МБ |
Разница не в том, что DuckDB «быстрее написан». Просто он не делает лишнего: не материализует то, что не спросили, и умеет считать агрегаты потоком.
Где всё-таки не подошло
Не заменяет pandas там, где нужна построчная логика на Python — какая-нибудь хитрая нормализация текста с регулярками и словарём исключений. Для этого по-прежнему удобнее вытащить уже отфильтрованный кусок в датафрейм и работать с ним.
И не заменяет базу: конкурентная запись, права, транзакции между сессиями — не сюда. Это инструмент для анализа файлов, а не хранилище.
Практическое правило, к которому пришёл: тяжёлое сужение делает DuckDB,
последнюю милю — pandas. .df() в конце запроса как раз про это.