DuckDB 2.0.0 LTS “Cinnamon Teal” 출시

AI 요약

DuckDB 팀이 1.5 이후 약 2만 건의 커밋을 반영한 2.0.0 LTS를 출시했습니다. 이번 버전은 안정성과 하위 호환성에 초점을 맞췄던 1.0과 달리 기능을 크게 확장한 릴리스입니다. 2.0은 최소 2027년 10월까지 지원합니다. 이전 LTS인 1.4는 2026년 11월 말까지 지원하며, 1.5 지원 기간도 2027년 3월까지 연장했습니다.

연결과 비동기 I/O

DuckDB 1.5.3에서 선보인 Quack 프로토콜을 다듬어 성능과 안정성을 개선했습니다. 새 CONNECT 문으로 원격 데이터베이스에 연결하고 세션을 전환할 수 있으며, 대상은 Quack뿐 아니라 PostgreSQL과 MySQL도 포함합니다. 원격 푸시다운 최적화는 쿼리를 원격 서버에서 실행해 테이블을 통째로 가져오는 일을 줄입니다. Quack 서버는 기본 설정에서 로컬호스트만 수신합니다. 다른 머신의 연결을 받으려면 TLS를 처리하는 리버스 프록시 뒤에 서버를 두라고 안내합니다.

Parquet, CSV, DuckDB 자체 저장 형식의 읽기에 비동기 I/O를 도입했습니다. 쿼리 처리와 I/O를 독립적으로 운영해 백그라운드에서 읽기를 요청하고 여러 요청을 동시에 처리합니다. 특히 S3 같은 오브젝트 스토리지에서 원격 데이터를 읽을 때 병렬성을 높이는 설계입니다.

데이터 형식과 CLI

VARIANT는 행마다 구조가 다른 반정형 데이터를 저장하는 형식입니다. 2.0은 데이터의 공통 구조를 찾아 열 형태로 분해해 압축과 실행 성능을 높이고, 저장소에서 직접 처리하는 실행 경로와 Parquet 읽기·쓰기까지 연결했습니다. 관련 함수군 variant_*도 제공합니다.

CLI는 Claude Code, Codex, Cursor 같은 코딩 에이전트가 실행하는 상황을 감지해 agent mode로 전환합니다. 결과를 간결한 Markdown 표로 출력하고, 잘린 결과를 알리며, 오래 실행되는 쿼리를 조기에 멈추고, 오류를 JSON으로 보고합니다. 실행 전 장기 쿼리의 예상 비용도 알려줍니다. DuckDB 팀이 TPC-H 실험에서 측정한 결과, agent mode는 모델이 읽어야 하는 출력량을 59% 줄였습니다. -agent 옵션으로 직접 켤 수 있습니다.

파서, 확장, 트리거

기존 PostgreSQL 계열 파서를 대신해 PEG 기반 파서를 기본값으로 전환했습니다. 확장이 문법에 새 구문을 추가할 수 있고 오류 메시지에는 정확한 소스 위치가 표시됩니다. 기존 파서로 되돌리려면 legacy_parser 확장을 사용합니다. 새 C API v2는 파일시스템과 테이블 함수를 확장에 노출하지만 아직 안정화 전입니다. 조직이 RSA 공개키로 서명한 확장을 자체 저장소에서 배포하는 기능도 들어갔으며, 이 기능은 작업 중이라 문법이 바뀔 수 있습니다.

CREATE TRIGGER로 행이나 문장 단위의 BEFORE·AFTER 트리거를 만들 수 있습니다. 전이 테이블에서 변경 전후 데이터를 읽고, 여러 트리거를 같은 이벤트에 등록하는 기능도 지원합니다. 예제에서는 INSERT와 DELETE 트리거가 합계와 인원수를 갱신해 국적별 평균 나이를 유지합니다. 일부 조합은 아직 지원하지 않습니다. 트리거는 증분 구체화 뷰를 구현하는 데도 활용할 수 있습니다.

그 밖에 $variable 문법, 데이터 수정 CTE, NEAREST 조인, 중첩 스키마, JSON 변경 함수가 추가됐습니다. DuckLake 1.1과 Iceberg·Delta 확장 개선도 함께 소개했습니다.

업그레이드와 호환성

2.0에서 만든 데이터베이스 파일은 2.0 이전 버전에서 읽을 수 없습니다. 반대로 기존 데이터베이스 파일은 2.0에서 읽고 쓸 수 있습니다. 팀은 운영 전 섀도 시스템에서 시험할 것을 권하고, 업무상 중요한 환경은 11월 패치 릴리스까지 기다리는 방안도 제시합니다. C++17 컴파일러가 필요하며 릴리스 빌드의 기본 컴파일러를 Clang으로 바꿨습니다. 단일 화살표 람다 문법은 기본 비활성화되고 2.1에서 제거될 예정입니다. macOS x86-64는 2.1부터 지원 대상에서 빠집니다.

Hacker News 반응

• @xnx — 정말 훌륭한 소프트웨어입니다. 분석 엔진으로 쓰는 것을 넘어 데이터를 가져오고 형태를 바꾸는 데도 놀라울 만큼 다재다능합니다. 팀에 감사드립니다.
• @RobinL — EC2의 코어 수가 많은 머신에서 DuckDB 2.0이 훨씬 빨라졌습니다. S3 읽기뿐 아니라 실제 계산도 그렇습니다. 약 128~192 vCPU까지 CPU 사용률이 100%에 가까워지고, 그 사용량이 작업 완료 시간 단축으로 이어집니다. 보통 192 vCPU를 넘어서는 속도 향상은 보지 못하지만, 2.0 전에는 속도가 64 vCPU쯤에서 정체됐습니다. 덕분에 오픈소스 레코드 연결 소프트웨어 Splink로 10억 레코드와 100억 건의 비교를 10분 안에 처리했습니다. 대부분의 성능 향상은 큰 계산을 DuckDB 엔진에 맡긴 데서 나왔습니다.
  • @dicey — Splink와 DuckDB를 함께 쓰는 방식이 마음에 듭니다. DuckDB 성능이 좋아지면서 Spark 기반 대규모 워크플로를 덜 쓰게 되나요? DuckDB로 처리할 수 있다면 Spark의 복잡성을 정당화하기 어려워 보입니다. 그래도 사용자가 Spark를 찾는 이유가 있는지 궁금합니다.
  • @RobinL — 여전히 Spark를 쓰는 사람은 있지만 대개 성능보다 플랫폼과 인프라 제약 때문입니다. Databricks에서는 대형 머신에서 DuckDB를 쓰기 어렵기도 하고 Spark에 익숙한 경우도 있습니다. 실행 환경을 자유롭게 고를 수 있는 신규 사용자라면 DuckDB를 권합니다. Splink 5는 작업을 여러 덩어리로 나눠 여러 머신에 분산할 수 있고, DuckDB 2.0은 대형 머신의 병렬 처리도 개선했습니다. 정말 거대한 데이터가 아니라면 Spark는 복잡하고 튜닝하기 어렵기 때문에 대부분의 작업에 필요하지 않다고 생각합니다.
  • @gopalv — 비동기 I/O는 병목이 디스크에서 CPU로 옮겨갈 때 CPU 사용량도 높이는 경우가 있습니다. 스캔 속도가 개선되면 다른 연산자도 단위 시간에 더 많은 일을 합니다. 코어 사용률이 100%에 가까운 것은 흐름이 원활하다는 신호지만, 그 다음 최적화에는 데이터 배치 변경이 필요할 수 있습니다.
  • @RobinL — DuckDB에서는 병렬 처리를 지나치게 늘리면 전체 실행 시간이 오히려 길어지기도 합니다. CPU가 100%로 돌아도 병렬화 오버헤드가 생깁니다. S3에서 로컬 SSD로 데이터를 옮긴 뒤 처리할 때도 관찰했습니다.
• @paoliniluis — 이제 클라이언트-서버 구조로 쓸 수 있다는 점이 판도를 바꿉니다. CPU와 메모리를 잔뜩 쓰는 여러 서버로 구성한 데이터 스택을 대체할 것 같습니다.
  • @bambax — 서버라고 해도 실제로는 여전히 프로세스 안에서 동작하므로 가볍고 단순합니다. 정말 좋습니다.
  • @jtbaker — HTTP 서비스나 로드 밸런서 뒤에 두고 자원 사용량에 따라 수평 확장하거나 Cloud Run처럼 0으로 축소할 수 있겠네요.
• @fragebogen — Parquet와 CSV를 읽는 비동기 I/O를 지원한다면 DuckDB 자체 형식도 이미 비동기 I/O를 지원하나요?
  • @adrian_b — 현재는 자체 형식도 지원하는 쪽입니다. 다른 형식인 JSON은 동기 I/O를 사용합니다. 원격 접근에서 효과가 가장 크지만 로컬의 콜드 읽기도 효과가 있습니다. 다음에는 JSON 읽기를 추가할 계획이며 외부 확장 형식은 현재 계획에 없습니다.
  • @pdet — DuckDB 형식도 비동기 I/O를 지원합니다. 저는 Parquet, CSV, DuckDB 형식의 비동기 I/O를 구현한 DuckDB 개발자입니다.
• @pletnes — CSV와 Parquet에 비동기 I/O를 적용하면 어떤 이점이 있나요?
  • @jtbaker — S3나 HTTP/S처럼 네트워크 지연이 있고 쿼리에서 여러 파일을 읽을 때 효과가 가장 큽니다. 로컬 I/O에서도 비슷한 효과가 있겠지만 지연 시간이 낮아 개선 폭은 작을 것 같습니다.
  • @skeeter2020 — 데이터를 기다리느라 놀고 있는 작업 스레드가 생기지 않으므로 사용 가능한 대역폭을 더 잘 활용하고 성능도 좋아집니다.
• @nicoritschel — 적당히 큰 클라우드 VM에서 특히 빠르며 Iceberg 쿼리도 그렇습니다. 소규모 조직의 중앙 분석 서버로 알파 버전을 운영해 왔습니다. PostgreSQL 와이어 프로토콜이나 Arrow Flight로 연결하는 DuckDB 확장을 만들었습니다. Quack 클라이언트 지원은 아직 제한적이지만 많은 데이터 도구가 PostgreSQL 와이어 프로토콜이나 ADBC를 지원합니다.
• @mikkelam — DuckDB를 쓰고 싶지만 회사에서 어떤 용도로 쓸지 찾기 어렵습니다. 다른 사람들은 어디에 쓰나요?
  • @jtbaker — 로그 처리와 집계 도구를 만들어 보세요.
  • @tcdent — Parquet 파일을 쓰는 Rust 프로파일러에 썼습니다. DuckDB로 실행 기록을 요약하고 분석하며 조인하기 쉽습니다.
  • @skeeter2020 — 개인이나 소규모 팀이 쓰는, 아주 크지는 않은 데이터가 있나요? 데이터가 MB나 GB 단위라면 데이터를 로컬에 제공해 권한 관리와 쿼리 보안 문제를 줄이면서 DB 도구와 성능을 제공할 수 있습니다. 원본 시스템에서 데이터를 추출해 Parquet 파일로 만들고 DuckDB로 보고서나 임시 분석에 쓰는 방식입니다. 제 경험으로는 한 번 드는 작업이 평생의 확장과 접근 제어 문제를 대신할 수 있습니다. 대부분 회사의 데이터는 몇 TB 정도라 DuckDB로 충분합니다.
  • @jdnier — CSV와 JSON 파일을 보는 데 씁니다. 형식 변환도 한 줄이면 됩니다.
  • @gopalv — 서버와 브라우저에서 같은 SQL로 데이터를 조회합니다. 데이터 배치를 잘 잡으면 duckdb-wasm으로 16~20MB 안에 약 200만~300만 행을 브라우저 쿼리 엔진에 넣을 수 있습니다. HTTP 범위 요청과 캐시 제어를 쓰면 약 1GB까지 늘릴 수 있습니다. 사용자는 각자 CPU로 DuckDB를 실행하므로 3,000명이 접속해도 데이터 큐브의 컴퓨팅 확장 문제를 해결할 수 있습니다.
  • @llimllib — duckdb-wasm에서 범위 요청을 쓰려면 현재 builtin_httpfs를 꺼야 합니다. 그렇지 않으면 필요 이상으로 많은 데이터를 가져올 수 있습니다.
  • @tomjakubowski — 이번 주 DuckLake 성능 문제를 디버깅하면서 read_parquet()가 Parquet 푸터를 읽으려고 S3에 작은 범위 요청을 많이 보내는 현상을 이해하지 못했습니다. 이 댓글 덕분에 해결 방향을 찾았습니다. 감사합니다.
  • @paoliniluis — 스프레드시트 같은 회사 안의 여러 데이터 소스를 연결하는 연합 쿼리 엔진으로 쓸 수 있습니다.
• @jiggawatts — DuckDB 2.0으로 Azure 로그 7TB를 중간급 VM에서 2시간 안에 압축해 원래 크기의 2.5%인 Parquet으로 만들었습니다. 아카이브 Blob Storage에서 수십 초 안에 임시 쿼리를 실행할 수 있었습니다. 서버 없이 보안 분석가에게 서명된 Blob URL을 전달했습니다. KQL 문법도 지원하면 완벽하겠습니다.
• @skybrian — 작은 프로젝트의 주 데이터베이스로 DuckDB를 써서 트랜잭션을 처리하면 어떨까요?
  • @netcraft — 단일 쓰기 작업자라면 꽤 멀리 갈 수 있습니다.
  • @dbettin — 분석 시스템을 써 본 사람은 DuckDB가 트랜잭션을 처리하지 못한다고 생각할 수 있지만, DuckDB는 처음부터 MVCC와 트랜잭션 격리를 갖춘 다중 연결 데이터베이스로 만들어졌습니다. 클라이언트-서버 방식이 다중 사용자와 장기 실행 배포에서 그 기능을 드러내게 합니다.
  • @andyferris — 실제 사용 사례나 벤치마크 링크가 있나요? PostgreSQL과 경쟁할 만큼 빠르다는 주장을 뒷받침한 내부 벤치마크도 궁금합니다.
  • @throwawaythekey — 트랜잭션은 처리할 수 있겠지만 DuckDB가 설계된 목적과는 반대입니다. 재미로 하는 경우에만 시도하세요.

원문: DuckDB Blog / 번역·요약: Trawling