본문 바로가기
  • plotly로 바로쓰는 동적시각화 in R & 파이썬
EPL과 유튜브 데이터로 배우는 DuckDB

DuckDB와 다른 DB 비교해보기

by 아참형인간 2026. 5. 9.

https://2stndard.tistory.com/notice/203

 

[발간예정][EPL과 유튜브로 배우는 DuckDB] 실습 코드와 데이터

EPL과 유튜브 데이터로 배우는 DuckDB에서 사용되는 실습 데이터와 코드를 제공합니다. EPL_DATA&samplefile.zip : 책에서 사용하는 영국 프리미어리그 데이터 셋과 샘플로 사용하는 파일espn.duckdb.zip : 책

2stndard.tistory.com

 

DuckDB란?

DuckDB는 임베디드(embedded) 방식의 인-프로세스(in-process) 분석용 데이터베이스입니다. 서버도, 설정도, 외부 의존성도 필요 없습니다. 라이브러리처럼 호스트 프로세스 내부에서 완전히 실행됩니다.

DuckDB는 컬럼 기반 벡터화 쿼리 실행 엔진(columnar-vectorized query execution engine)을 사용합니다. 이는 PostgreSQL이나 SQLite처럼 행(row) 단위로 처리하는 것이 아니라, 대량의 값 데이터 세트(벡터)를 한 번의 작업으로 처리한다는 뜻입니다. 바로 이 설계 방식이 분석 작업에서 DuckDB가 압도적으로 빠른 이유입니다.

DuckDB vs. SQLite

둘 다 임베디드 방식이며 서버가 필요 없다는 공통점이 있습니다. 하지만 이외에는 매우 다릅니다.

  • SQLite: 데이터 저장시 행 단위로 저장합니다. 특정 데이터를 검색하는 포인트 조회(point lookups)에는 훌륭하지만, 대량 데이터를 사용해야 하는 분석 작업에는 상대적으로 느립니다.
  • DuckDB: 데이터 저장시 열 단위로 저장합니다. 예를 들어 "서울시 고객의 평균 주문 금액"을 계산해야 한다면, 필요한 두 개의 컬럼만 읽고 나머지는 모두 건너뛸수 있습니다.
  • 성능 차이: 복잡한 분석 쿼리에서 DuckDB는 SQLite보다 최대 113배 더 빠를 수 있다고 합니다.

SQLite가 유용한 어플리케이션: 모바일/데스크톱 앱 구축, 단순 트랜잭션 저장소 어플리케이션, ACID 위주의 트랜잭션이 빈번한 어플리케이션.
DuckDB가 유용한 어플리케이션: 집계(aggregation), 분석, 또는 로컬에서 대규모 테이블을 조인(join)이 빈번한 어플리케이션.

DuckDB vs. PostgreSQL

  • 데이터 로딩: 1,000만 개의 행을 Postgres에 로드하는 데 약 7분이 걸리지만, DuckDB는 별도의 수집(ingestion) 단계 없이 CSV를 직접 쿼리하여 12초 만에 처리한다고 합니다.
  • 집계 성능: 5,000만 행 기준, Postgres는 약 25초, DuckDB는 약 8초가 소요됩니다.
  • 헤비 분석 조인: Postgres는 40~50초, DuckDB는 약 12초가 소요됩니다.

 

Postgres가 여전히 우세한 부분

  • 인덱스 기반 포인트 조회: WHERE id = ?와 같은 쿼리에서 Postgres는 밀리초 단위로 응답합니다. DuckDB는 이러한 인덱스 구조가 없습니다.
  • 동시 접속: Postgres는 여러 사용자를 원활하게 처리하지만, DuckDB는 단일 프로세스 중심입니다.

최적의 조합: Postgres를 기본 트랜잭션 DB로 사용하고, 메인 DB에 부하를 주지 않으면서 복잡한 보고서를 뽑아내는 임베디드 분석 레이어로 DuckDB를 활용하세요.

 

DuckDB vs. Apache Spark

 

이 부분이 DuckDB가 가장 우수한 성능을 보이는 부분입니다.

  • Spark는 여러 머신에 걸쳐 메모리를 초과하는 데이터를 처리하기 위해 만들어졌습니다. 하지만 10GB에서 500GB 사이의 데이터 범위라면 DuckDB가 더 간단하고 빠릅니다.
  • Spark의 운영 비용(클러스터 설정, JVM 튜닝, 버전 호환성)은 DuckDB가 노트북 한 대에서 동일한 작업을 처리할 수 있는 상황에서는 낭비에 가깝습니다.
  • DuckDB는 pip 설치가 가능한 단일 바이너리로 시작 시간이 거의 제로에 가깝지만, Spark는 그렇지 않습니다.

Spark가 여전히 우세한 부분: 데이터가 실제로 수백 GB에서 TB 단위에 이르러 분산 컴퓨팅이 반드시 필요한 경우.

 

DuckDB vs. 클라우드 데이터웨어하우스(Snowflake / BigQuery)

 

  • DuckDB는 Parquet 파일을 네이티브로 읽습니다. 파일 자체가 데이터베이스가 되므로 별도의 수집 단계가 필요 없습니다.
  • 클라우드 데이터 웨어하우스는 쿼리 전 ETL 과정이 필요하며, 이는 탐색 단계에서 시간과 비용이 필요합니다.
  • 로컬 반복 작업 및 실험 시, DuckDB는 속도와 비용 면에서 압승입니다 (무료 vs 쿼리당 과금).

클라우드 데이터웨어하우스가 여전히 우세한 부분: TB급 규모의 데이터, 팀 협업, 거버넌스 공유, 다수의 동시 사용자 환경

 

결론


DuckDB는 1MB에서 500GB 규모의 로컬 분석 작업에 있어 가장 적합한 도구입니다. 트랜잭션 처리 작업에는 Postgres를, 진정한 분산 데이터 처리에는 Spark를 대체하지는 않습니다. 그러나 그 사이의 모든 작업에 있어서는 속도, 간편성, 그리고 인프라 비용이 전혀 들지 않는다는 점에서 단연 돋보입니다.

 

 

출처: https://medium.com/ai-in-plain-english/duckdb-vs-everything-else-the-complete-comparison-e1cf6bbbe0bc

댓글