# DuckDB가 데이터 처리할 때 나의 첫 번째 선택인 이유 > Clean Markdown view of GeekNews topic #25910. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25910](https://news.hada.io/topic?id=25910) - GeekNews Markdown: [https://news.hada.io/topic/25910.md](https://news.hada.io/topic/25910.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-18T06:35:09+09:00 - Updated: 2026-01-18T06:35:09+09:00 - Original source: [robinlinacre.com](https://www.robinlinacre.com/recommend_duckdb/) - Points: 30 - Comments: 2 ## Summary **DuckDB**는 단일 머신에서 대규모 데이터를 빠르게 처리할 수 있는 **인프로세스 SQL 엔진**으로, 별도 서버 없이도 고성능 분석 쿼리를 실행합니다. Python 환경에서 즉시 설치·실행이 가능해 **CI와 테스트 자동화**에 특히 유용하며, `csv`, `parquet`, `json` 파일을 직접 쿼리할 수 있습니다. 친화적인 SQL 확장과 ACID 보장, PostgreSQL 통합 확장 덕분에 중간 규모 데이터 처리에서 **레이크하우스의 실용적 대안**으로 자리 잡고 있습니다. ## Topic Body - **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·로컬 파일** 등에서 데이터를 직접 쿼리 가능 - 예: `read_parquet('https://.../flights.parquet')` 형태로 원격 Parquet 파일 조회 - **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 인덱스 최적화 및 필터 푸시업 개선** 후 **광범위한 채택 가능성** 있음 ## Comments ### Comment 49417 - Author: kaydash - Created: 2026-01-18T14:52:54+09:00 - Points: 2 분산처리를 위한 parq를 단일머신에서 처리할 목적으로 쓴다는건 아이러니하네요 ### Comment 49401 - Author: neo - Created: 2026-01-18T06:35:09+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46645176) - 내가 **DuckDB**를 좋아하는 이유는 다양함 `.parquet`, `.json`, `.csv` 파일을 모두 지원하고, `select * from 'tsa20*.csv'`처럼 **glob 읽기**가 가능해 수백 개 파일을 하나처럼 다룰 수 있음 스키마가 달라도 `union_by_name`으로 쉽게 합칠 수 있고, **CSV 파서**가 타입을 자동으로 잘 지정해줌 WebAssembly 버전은 2MB, CLI는 16MB로 매우 작음 이 덕분에 제품에 직접 포함할 수 있음. 예를 들어 [Malloy](https://www.malloydata.dev/)처럼 말임 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 함수](https://clickhouse.com/docs/sql-reference/table-functions/s3Cluster), [schema inference](https://clickhouse.com/docs/interfaces/schema-inference), [PR #55892](https://github.com/ClickHouse/ClickHouse/pull/55892) - 나는 **Shaper**를 만들었는데, Malloy의 아이디어처럼 데이터 쿼리와 시각화를 결합함 다만 Shaper는 별도 언어 대신 SQL을 사용함 DuckDB를 기반으로 **SQL만으로 대시보드**를 만들 수 있음 [Shaper GitHub](https://github.com/taleshape-com/shaper) - 나는 [ZenQuery](https://zenquery.app)를 만들었고 내부 처리에 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](https://sqg.dev/generators/java-duckdb-arrow/)로 DuckDB SQL 쿼리에서 직접 코드를 생성함 - 기술 스택이 궁금함. 내부 구조를 다룬 글이 있는지 알고 싶음. HN 도구도 인상적임 - **Java** 프로젝트인 [manifold-sql](https://github.com/manifold-systems/manifold/blob/master/docs/articles/duckdb_info.md)을 소개하고 싶음 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 통합도 인상적임 이런 **작은 엔진들**이 더 많이 등장해 경쟁과 혁신이 이어지길 바람