▲

DuckDB가 데이터 처리할 때 나의 첫 번째 선택인 이유

 (robinlinacre.com)
15P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • DuckDB는 단일 머신에서 대규모 테이블 데이터를 빠르고 간단하게 처리할 수 있는 오픈소스 SQL 엔진으로, 최근 데이터 엔지니어링에서 널리 사용됨
  • 설치가 간단하고 의존성이 없으며, Python 환경에서 즉시 실행 가능해 CI·테스트 자동화에 적합함
  • 분석 쿼리 최적화로 SQLite나 Postgres보다 최대 1,000배 빠른 성능을 보이며, 다양한 파일 형식(csv, parquet, json)을 직접 쿼리 가능
  • 친화적인 SQL 문법(EXCLUDE, COLUMNS, QUALIFY, 함수 체이닝 등)과 Python API를 통해 복잡한 파이프라인을 효율적으로 개발 가능
  • ACID 준수, 고성능 UDF, PostgreSQL 통합 확장 등으로 중간 규모 데이터의 레이크하우스 대안으로 부상 중

DuckDB 개요

  • DuckDB는 애널리틱스 쿼리 최적화에 초점을 둔 인프로세스 SQL 엔진
    • 별도 서버 없이 애플리케이션 내부에서 실행되며, Postgres 같은 외부 서비스가 필요 없음
    • 대량의 조인·집계 연산에 특화되어 있으며, 트랜잭션 중심 엔진(OLTP)보다 최대 100~1,000배 빠른 성능 제공
  • 주요 사용 사례는 csv, parquet, json 등 대형 파일을 디스크에서 직접 읽어 일괄 처리(batch processing) 하는 경우
  • 명령줄에서 간단히 CSV 파일을 조회하는 등 경량 데이터 탐색에도 활용 가능

주요 특징

  • 속도

    • DuckDB는 가장 빠른 오픈소스 데이터 처리 엔진 중 하나로 벤치마크에서 상위권 유지
    • Polars, DataFusion, Spark, Dask 등과 비교 시, 소규모 데이터에서는 DuckDB가 우세, 대규모 데이터에서는 Spark·Dask가 경쟁력 있음

  • 간단한 설치와 무의존성

    • DuckDB는 단일 사전 컴파일 바이너리 형태로 제공되며, Python에서는 pip install duckdb로 즉시 설치 가능
    • 의존성 없음으로 Spark 등 대형 프레임워크 대비 설치가 매우 간단
    • uv와 결합 시 1초 이내 Python 환경 구성 가능

  • CI 및 테스트

    • 빠른 시작 속도와 경량성 덕분에 데이터 파이프라인의 CI·테스트 환경에 적합
    • 과거 Spark 기반 테스트는 느리고 복잡했으나, DuckDB는 환경 설정 단순화와 프로덕션과의 일관성 유지가 용이

  • SQL 작성 경험

    • DuckDB는 SQL 작성 및 구문 검증을 빠르게 수행 가능
    • Spark 로컬 모드나 AWS Athena보다 즉시 실행 및 반복 개발에 유리
    • 자동완성 기능을 갖춘 UI 제공

  • 친화적인 SQL 문법

    • DuckDB는 사용자 친화적 SQL 확장을 다수 포함
      • EXCLUDE, COLUMNS, QUALIFY, 윈도 함수 집계 수정자, 함수 체이닝(first_name.lower().trim()) 등 지원
    • 이러한 기능은 복잡한 컬럼 선택·변환 작업을 간결하게 수행

  • 다양한 파일 형식 지원

    • S3·웹 URL·로컬 파일 등에서 데이터를 직접 쿼리 가능
    • CSV 타입 엄격성 옵션을 제공해 비정형 입력 데이터로 인한 오류 방지

  • Python API

    • Python에서 CTE 기반 파이프라인을 단계별로 정의하고, 각 단계 데이터를 손쉽게 점검 가능
      • duckdb.sql() 호출로 SQL을 체인 형태로 연결
      • 지연 실행(lazy execution) 으로 성능 손실 없이 중간 결과 확인 가능
    • 각 단계별 함수 테스트가 가능해 CI 테스트 효율성 향상

  • ACID 준수

    • DuckDB는 대용량 데이터 작업에서도 완전한 ACID 보장
    • 이 특성으로 Iceberg·Delta Lake 같은 레이크하우스 포맷의 중간 규모 대체재로 활용 가능

  • 고성능 UDF 및 커뮤니티 확장

    • C++로 고성능 사용자 정의 함수(UDF) 작성 가능
    • Community Extensions를 통해 INSTALL h3 FROM community 같은 명령으로 즉시 확장 설치 가능
      • 예: 지리공간 데이터용 육각형 인덱싱(h3) 지원

  • 문서화

    • 전체 문서를 단일 Markdown 파일로 제공해 LLM 학습이나 코드 편집기 내 검색에 용이
    • 코드 폴딩 기능으로 필요한 부분만 쉽게 복사 가능

실제 활용 및 효과

  • 오픈소스 Splink 프로젝트에서 DuckDB를 기본 백엔드로 채택한 결과
    • 사용자 문제 감소, 작업 속도 향상, 기능 개발·테스트 단순화 달성

주목할 확장 기능

  • PostgreSQL Extension: DuckDB에서 Postgres 데이터베이스를 직접 연결·쿼리 가능
  • pg_duckdb: Postgres 내부에 DuckDB 엔진을 임베드해 트랜잭션·분석 처리 병행 가능
    • 향후 Postgres 인덱스 최적화 및 필터 푸시업 개선 후 광범위한 채택 가능성 있음
▲
kaydash 17시간전  [-]

분산처리를 위한 parq를 단일머신에서 처리할 목적으로 쓴다는건 아이러니하네요

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • 내가 DuckDB를 좋아하는 이유는 다양함
    .parquet, .json, .csv 파일을 모두 지원하고, select * from 'tsa20*.csv'처럼 glob 읽기가 가능해 수백 개 파일을 하나처럼 다룰 수 있음
    스키마가 달라도 union_by_name으로 쉽게 합칠 수 있고, CSV 파서가 타입을 자동으로 잘 지정해줌
    WebAssembly 버전은 2MB, CLI는 16MB로 매우 작음
    이 덕분에 제품에 직접 포함할 수 있음. 예를 들어 Malloy처럼 말임
    Malloy는 PowerBI나 Tableau의 기술자 버전 같은데, 의미 기반 모델을 사용해 AI가 더 나은 쿼리를 작성하게 도와줌. SQL을 10배 쉽게 쓰게 해주는 느낌임

    • DuckDB의 CSV 지원 덕분에 데이터 탐색 방식이 완전히 바뀌었음
      예전엔 스키마를 먼저 이해하려고 시간을 썼지만, 지금은 데이터를 불러와 탐색 쿼리를 쓰고, 가정 검증 후 정제·변환·테이블 생성 과정을 반복함
      덕분에 훨씬 빠르게 깊이 파고들고, 막다른 길도 빨리 발견해 시간 낭비를 줄임
      CSV 파서의 작동 방식과 향후 개선 아이디어를 다룬 논문이 있다고 들었는데, 아직 찾지 못했음
    • 최근 ClickHouse를 많이 써봤는데 DuckDB와 비슷한 장점이 많음
      특히 Parquet과 JSON ingestion이 편리하고, clickhouse-local은 DuckDB를 내장하는 개념과 유사함
      SELECT ... FROM s3Cluster(...) 구문으로 S3 버킷에서 와일드카드 ingest가 가능하고, 클러스터 노드에 분산 처리됨
      schema_inference_mode도 지원하는 듯함
      ClickHouse도 union_by_name과 유사한 기능을 구현했음
      관련 문서: s3Cluster 함수, schema inference, PR #55892
    • 나는 Shaper를 만들었는데, Malloy의 아이디어처럼 데이터 쿼리와 시각화를 결합함
      다만 Shaper는 별도 언어 대신 SQL을 사용함
      DuckDB를 기반으로 SQL만으로 대시보드를 만들 수 있음
      Shaper GitHub
    • 나는 ZenQuery를 만들었고 내부 처리에 DuckDB를 사용함
      속도가 놀랍고, 스키마 자동 감지가 대부분 정확하게 작동함
      LLM이 자연어 질의로 올바른 SQL을 생성해줌
    • 이건 정말 훌륭한 소개임
      나는 SQLite로 수동 import를 하던 방식이었는데, DuckDB 덕분에 훨씬 간단해졌음

  • 나도 DuckDB를 즐겨 쓰는 사람임
    BC 해안 환경을 연구하는 과학자들과 함께 일하면서, 빙하 관측부터 심해 드론 데이터까지 엄청난 양의 데이터를 다룸
    새로운 생물다양성 데이터 변환 도구의 엔진으로 DuckDB를 채택했는데, Darwin Core 표준으로 데이터를 변환·검증하는 게 목표임
    DuckDB 테이블을 스키마 기반으로 동적으로 생성하고 데이터를 import함. 실패 시 행 단위로 이유를 알려줌
    변환과 검증도 전부 DuckDB 내에서 수행함
    이 덕분에 훨씬 빠르고, 강력하고, 브라우저에서도 실행 가능한 애플리케이션을 만들었음
    현장 연구자들이 iPad 브라우저에서 오프라인으로 쓸 수도 있음
    DuckDB 덕분에 SQL이 무거운 일을 대신해주는 신뢰감이 생김
    타입 안정성이 부족한 부분은 파싱과 테스트로 보완함
    이 프로젝트는 과학자들이 공통 도구로 생물다양성·유전체 데이터를 분석하고 공개 저장소에 게시할 수 있게 하는 게 목적임

    • 기존 데이터셋은 어떤 포맷인지 궁금함
      나는 과학 데이터 처리에서 HDF5를 자주 다루는데, DuckDB는 기본적으로 HDF5를 지원하지 않음
      기존 확장은 느리고 기능이 부족해서 C++ 템플릿으로 새 확장을 만들었음
      협업에 관심 있는 사람을 찾고 있음
    • 같은 작업에 Polars를 쓰면 어떤 장점이 있는지 궁금함
      개인적으로 Polars 문법이 SQL보다 훨씬 편해서, DuckDB를 시도해볼 가치가 있는지 고민 중임

  • 우리는 Bluesky의 분석과 피드 처리를 DuckDB로 수행함
    결과를 빠르게 얻기 위해 Apache Arrow 인터페이스를 사용하고, SQG로 DuckDB SQL 쿼리에서 직접 코드를 생성함

    • 기술 스택이 궁금함. 내부 구조를 다룬 글이 있는지 알고 싶음. HN 도구도 인상적임

  • Java 프로젝트인 manifold-sql을 소개하고 싶음
    DuckDB SQL을 타입 세이프하게 인라인으로 작성할 수 있음
    SQL을 코드 안에 직접 넣고 .fetch()로 결과를 순회할 수 있어, 중간 계층 없이 깔끔함

  • 글쓴이의 주장은 기본적인 데이터 처리에는 타당하지만,
    “대부분의 테이블 데이터는 단일 머신에서 처리 가능하다”는 부분은 논쟁의 여지가 있음
    데이터 확장이나 피벗, 증강을 하다 보면 금방 메모리 초과(OOM) 가 발생함
    또한 “SQL이 새로운 데이터 엔지니어링의 첫 선택이 되어야 한다”는 주장도, 복잡한 분석에는 잘 맞지 않음

    • 글쓴이 본인임
      Polars나 pandas 같은 dataframe API도 장점이 많지만, 생태계가 표준화되지 않아 파이프라인을 자주 다시 써야 하는 게 문제임
      대부분의 데이터는 10GB 이하라서 단일 머신에서도 충분히 처리 가능함
      Spark를 과하게 쓰는 경우가 많음
      내 입장은 “DuckDB로 먼저 시도해보라”는 것임. 간단한 경우엔 빠르고 효율적임
    • ML이나 시각화처럼 고급 분석에는 dataframe이 더 적합함
      단순 파이프라인 처리엔 SQL이 좋지만, 가독성은 사람마다 다름
      나는 dataframe 쪽이 훨씬 읽기 쉬움
    • SQL은 여전히 배우기 쉽고, 데이터 모델링은 대부분 SQL로 이루어짐
      ingestion 쪽은 Python이나 Scala가 많지만, SQL은 사라지지 않을 것임
    • 나는 500GB의 Parquet 데이터를 DuckDB로 처리하고 있는데, 50GB RAM 데스크탑에서도 부드럽고 빠름
      OOM은 극단적인 경우에나 문제 될 듯함
    • Polars도 이런 장점을 대부분 가지고 있고, GPU·분산 백엔드까지 지원함
      DuckDB가 주목받는 만큼 Polars도 과소평가되고 있음

  • 나는 데이터 처리를 많이 하는데, 주로 Polars를 사용함
    매우 빠르고, pandas처럼 SQL로는 구현하기 어려운 함수들이 많음
    Python 함수도 바로 쓸 수 있음
    DuckDB가 성능이 같더라도 SQL의 표현 제약이 있을 것 같아 망설여짐

    • 내 경험상 DuckDB가 훨씬 빠르고 간결했음
      독립 실행형이라 설치도 간단하고, 튜닝이나 학습 곡선이 거의 없음

  • 메인프레임이 생성한 형식이 엉망인 Excel 파일을 DuckDB로 불러왔는데,
    all_varchar 옵션으로 1초도 안 돼 로드됨
    Excel은 아직도 파일을 여는 중임

  • DuckDB는 훌륭하지만, 동적 확장 로딩이 코드 서명과 충돌해 상용 앱에서 쓰기 어려움
    또 공간 확장은 LGPL 구성요소를 써서 라이선스 이슈가 있음
    Apache Arrow처럼 필요한 기능만 패키지 단위로 조합할 수 있으면 좋겠음
    예: HTTP로 GB/s 배열 전송은 Arrow Flight, 파일 공유는 Arrow IPC, Parquet 읽기는 별도 trait 추가
    DuckDB의 SQL 타입 시스템이 Arrow와 달라 타입 불일치 문제가 생길 수 있음
    Arrow는 대부분의 언어에서 네이티브 라이브러리를 제공함

  • 수십억 건의 거래 데이터(30개 컬럼)를 가진 단일 테이블에서
    WHERE 조건으로 필터링된 페이지를 빠르게 조회할 수 있는지 궁금함
    Postgres에서는 단순 count(*)도 오래 걸림

    • 이 정도 규모라면 DuckDB에서도 몇 초 이내로 끝날 것 같음
      느린 경우는 복잡한 조인이나 다수 파일 glob 처리뿐이었음
    • count 속도를 높이려면 인덱스보다는 주기적 캐싱이 나을 수 있음
      WHERE 조건이 단순한 컬럼-값 쌍이면 꽤 빠르게 처리될 것임

  • DuckDB는 단순히 빠른 DB가 아니라, 개발자 경험(devx) 이 훌륭함
    쉽게 시작할 수 있어 생태계가 빠르게 확장됨
    Web/WASM 통합도 인상적임
    이런 작은 엔진들이 더 많이 등장해 경쟁과 혁신이 이어지길 바람

답변달기