DuckDB 는 분석 질의를 위한 인프로세스 데이터베이스다. 서버를 따로 띄우지 않고 애플리케이션 프로세스 안에서 라이브러리로 동작한다는 점에서 SQLite 와 같은 자리에 있고, 행이 아니라 열 단위로 저장하고 벡터화해 실행한다는 점에서 SQLite 와 반대편에 있다. 한 대에서 끝나는 분석 작업이라면 클러스터를 세우는 대신 이쪽을 먼저 본다. MIT 라이선스다.
| 항목 | 내용 |
|---|---|
| 배포 형태 | 라이브러리 하나. 별도 서버 프로세스와 데몬이 없고 외부 의존성이 없다 |
| 실행 모델 | 열 지향 저장 + 벡터화 실행. 집계와 스캔이 많은 질의에 맞는다 |
| 저장 | 단일 파일(.duckdb)에 담거나, 아예 저장하지 않고 메모리에서만 쓴다 |
| 외부 파일 직접 질의 | Parquet · CSV · JSON 을 적재 없이 FROM 절에서 바로 읽는다 |
| 인터페이스 | CLI, Python, R, Java, Node.js, C/C++ |
| 메모리 초과 | 메모리보다 큰 데이터는 디스크로 흘려 처리한다. 다만 작업 디렉터리 여유가 필요하다 |
-- 적재 없이 파일을 바로 읽는다
SELECT order_date, SUM(amount)
FROM 'data/orders/*.parquet'
GROUP BY order_date;
-- 결과를 다시 파케이로 떨군다
COPY (SELECT * FROM orders WHERE amount > 1000)
TO 'out/big_orders.parquet' (FORMAT PARQUET);
오브젝트 스토리지를 읽으려면 확장을 붙인다.
INSTALL httpfs;
LOAD httpfs;
SET s3_region='ap-northeast-2';
SET s3_access_key_id='${AWS_ACCESS_KEY_ID}';
SET s3_secret_access_key='${AWS_SECRET_ACCESS_KEY}';
SELECT count(*) FROM 's3://bucket/warehouse/orders/*.parquet';
분석가 노트북에서 수십 기가바이트급 파케이를 뒤지는 일, ETL 중간 단계에서 판다스 대신 SQL 로 조인·집계하는 일, CI 에서 데이터 검증 쿼리를 돌리는 일에 잘 맞는다. 스파크 클러스터를 띄울 이유가 데이터 크기가 아니라 습관인 경우가 많은데, 한 대 메모리로 감당되는 범위라면 DuckDB 쪽이 훨씬 빠르고 단순하다.
반대로 다음 자리에는 맞지 않는다.