포지셔닝과 적합한 워크로드
DuckDB를 서버형 DB, 파일 포맷, 데이터프레임 도구와 비교해 언제 써야 하는지 정리합니다.
핵심 요약
- DuckDB는 별도 서버 없는 embedded OLAP 엔진으로, PostgreSQL 같은 트랜잭션 서버가 아니라 로컬 분석·검증·파일 레이크 탐색·데이터 마트 생성에 강합니다.
- 강한 사용 사례는 Parquet 레이크 탐색, CSV/JSON 수집 전 검증, Python notebook 가속, dbt local dev, BI용 소형 mart 생성입니다.
- 다중 프로세스 동시 write, DB 서버 내 권한·RLS·audit, 초당 많은 작은 트랜잭션, 장기 서비스 primary store, untrusted SQL 직접 실행이 중심이면 다른 시스템을 선택합니다.
- 도입 기준은 "얼마나 빠른가"보다 "실패했을 때 어떤 상태가 남는가"이며, 운영 DB의 복제본·export·Parquet lake를 분석하는 위치에 두는 것이 가장 안전합니다.
- production에서는 입력·출력·리소스·보안·동시성 경계를 문서화해 단일 writer 또는 read-only 다중 process로 제한합니다.
DuckDB를 잘 쓰려면 먼저 "무엇이 아닌지"를 정해야 합니다. DuckDB는 별도 서버를 운영하지 않는 embedded OLAP 엔진입니다. 애플리케이션 프로세스나 CLI 안에서 돌아가고, 분석 쿼리에 맞춘 columnar/vectorized 실행 모델을 씁니다. 그래서 PostgreSQL 같은 트랜잭션 서버와 경쟁하는 도구가 아닙니다. 로컬 분석, 검증, 파일 레이크 탐색, 데이터 마트 생성에 강합니다.
선택 기준
| 질문 | DuckDB가 맞는 경우 | 다른 도구가 나은 경우 |
|---|---|---|
| 데이터 위치 | 로컬 파일, Parquet lake, S3 prefix, Python 메모리 객체 | 중앙 warehouse에 이미 정제된 데이터 |
| 사용 패턴 | 한 명 또는 한 프로세스가 분석 쿼리를 반복 실행 | 많은 사용자가 동시에 쓰고 권한을 나눔 |
| 쿼리 특성 | 필터, 집계, window, join, 파일 변환 | 초당 많은 단건 write/update |
| 배포 모델 | CLI, notebook, batch job, embedded app | 장기 실행 DB 서버와 connection pool |
| 재현성 | SQL 파일과 입력 파일만 있으면 재실행 가능 | 실시간 서비스 상태와 긴 트랜잭션이 핵심 |
의사결정 흐름
강한 사용 사례
| 사용 사례 | 이유 | 산출물 |
|---|---|---|
| Parquet 데이터 레이크 탐색 | 컬럼 pruning, filter pushdown, metadata 함수가 강함 | 임시 mart, 품질 리포트 |
| CSV/JSON 수집 전 검증 | 자동 추론과 명시 스키마를 빠르게 비교 가능 | reject list, schema contract |
| Python notebook 가속 | Pandas/Polars/Arrow 객체를 SQL로 바로 질의 | 재현 가능한 SQL cell |
| dbt/analytics local dev | warehouse 없이 샘플 데이터로 모델 검증 | 로컬 모델 결과 |
| BI용 소형 mart 생성 | Parquet 또는 DuckDB file로 배포 가능 | .parquet, .duckdb |
피해야 할 사용 사례
DuckDB는 single-node 분석 엔진입니다. 다음 요구가 중심이면 처음부터 다른 시스템을 선택합니다.
- 여러 프로세스가 동시에 같은 DB 파일에 write해야 한다.
- 사용자별 권한, row-level security, audit log가 DB 서버 안에서 필요하다.
- 초당 많은 작은 트랜잭션과 낮은 write latency가 핵심이다.
- 장기 실행 서비스의 primary state store가 필요하다.
- untrusted SQL을 사용자가 직접 입력하고 실행한다.
DBA 관점의 핵심
DuckDB를 "작은 운영 DB"로 보면 실수합니다. 분석 엔진으로 보면 강합니다. 운영 데이터베이스의 복제본, export, Parquet lake, object storage snapshot을 분석하는 자리에 두는 것이 가장 안전합니다.
운영 경계
DuckDB 도입 기준은 "쿼리를 얼마나 빠르게 돌릴 수 있느냐"보다 "실패했을 때 어떤 상태가 남는가"입니다. CLI 분석은 실패해도 다시 돌리면 됩니다. 배치 job은 임시 디렉터리와 출력 경로를 지우고 재시도하면 됩니다. 하지만 서비스 요청 경로에서 DuckDB가 사용자 입력 SQL을 실행하면 CPU, 메모리, 디스크, 네트워크를 모두 잡아먹을 수 있습니다.
production에서 DuckDB를 쓴다면 다음 경계를 문서화합니다.
| 경계 | 권장 |
|---|---|
| 입력 | 파일 prefix, table macro, parameterized SQL로 제한 |
| 출력 | overwrite 가능한 staging 경로와 atomic publish 경로 분리 |
| 리소스 | memory_limit, threads, temp_directory, job timeout 설정 |
| 보안 | extension repository, network access, secret persistence 정책 명시 |
| 동시성 | 단일 writer process 또는 read-only 다중 process로 제한 |