DuckDB 2.0, 작은 분석 DB가 서버를 향하기 시작했다

파일 하나 열어 분석하던 DuckDB가 이제 PostgreSQL과 S3, 서버의 영역까지 넘보고 있다

데이터 분석을 하다 보면 항상 비슷한 고민을 하게 된다.

CSV 파일 몇 개를 분석하기 위해 데이터베이스 서버를 구축하기에는 너무 무겁다.

그렇다고 Python과 Pandas만으로 처리하기에는 데이터가 커지면서 메모리와 성능이 부담스럽다.

이 사이에서 빠르게 성장한 데이터베이스가 DuckDB다.

DuckDB는 별도의 데이터베이스 서버를 운영하지 않고도 애플리케이션 프로세스 안에서 SQL 분석을 수행할 수 있는 데이터베이스다.

그런데 2026년 가을 출시가 예정된 DuckDB 2.0에서는 이 정체성이 꽤 크게 확장된다.

DuckDB 개발팀은 이번 버전을 설명하면서 이렇게 방향을 잡았다.

지난해가 Lakehouse의 해였다면, 이번 릴리스는 DuckDB가 서버가 되는 해의 시작이다.

DuckDB 2.0은 단순한 성능 업데이트라기보다는 DuckDB가 어디까지 사용될 수 있는지 범위를 넓히는 버전에 가깝다.

v1.5 이후 10,000개 이상의 커밋이 들어갔고, SQL Parser와 Storage Format 같은 내부 구조까지 상당 부분 손봤다.

---

1. 가장 큰 변화, DuckDB가 서버가 된다

지금까지 DuckDB를 설명할 때 빠지지 않았던 특징이 있다.

In-process Database.

PostgreSQL이나 MySQL처럼 별도 데이터베이스 서버에 접속하는 구조가 아니라 프로그램 안에 DuckDB 엔진을 넣어 사용하는 방식이다.

그런데 DuckDB 2.0부터 여기에 새로운 선택지가 생긴다.

Quack Protocol

DuckDB의 새로운 네트워크 프로토콜인 Quack을 이용하면 DuckDB 데이터베이스를 네트워크를 통해 제공할 수 있다.

서버에서는 대략 다음과 같이 DuckDB를 서비스할 수 있다.

CALL quack_serve(
    token = 'my_token'
);

다른 DuckDB에서는 이 서버에 접속한다.

ATTACH 'quack:server.example.com'
    AS qk (TOKEN 'my_token');

CONNECT qk;

SELECT count(*)
FROM events;

DISCONNECT;

중요한 부분은 SELECT가 클라이언트에서 수행되는 것이 아니라 서버에서 실행되고 결과만 전달된다는 것이다.

DuckDB가 단순히

내 노트북 안에서 Parquet을 빠르게 분석하는 DB

에서

네트워크를 통해 여러 시스템이 접근하는 분석 엔진

으로 확장되기 시작한 셈이다.

---

2. 더 재미있는 것은 CONNECT다

CONNECT는 DuckDB 서버에만 사용하는 기능이 아니다.

PostgreSQL에도 연결할 수 있다.

CONNECT 'postgres://localhost/mydb';

SELECT count(*)
FROM orders;

DISCONNECT;

여기서 재미있는 점은 DuckDB가 PostgreSQL 테이블 전체를 가져와서 분석하는 것이 아니라는 것이다.

새로운 Remote Pushdown Optimizer가 SQL을 PostgreSQL이나 MySQL 쪽으로 전달해 가능한 연산을 원격 서버에서 수행한다.

구조적으로 보면 이런 그림이 가능해진다.

Application
     │
   DuckDB
     │
 ┌───┼─────────┐
 │   │         │
 ▼   ▼         ▼
S3 PostgreSQL MySQL
 │
Parquet

[Inference] 이렇게 보면 DuckDB가 단순한 데이터 저장소라기보다 여러 데이터 소스를 SQL로 연결하는 경량 분석 계층으로 활용될 가능성이 더 커진다.

---

3. JSON을 위한 새로운 무기, VARIANT

최근 데이터 시스템에서 JSON을 피하기는 어렵다.

로그도 JSON이고,

API 데이터도 JSON이고,

AI Agent의 결과도 JSON인 경우가 많다.

문제는 JSON이 편리한 대신 분석 효율이 좋지 않은 경우가 많다는 것이다.

DuckDB가 해결책으로 밀고 있는 것이 VARIANT 타입이다.

DuckDB 팀은 이를 사실상

JSON on steroids

라고 설명한다.

VARIANT는 한 컬럼 안에 서로 다른 구조의 데이터를 저장할 수 있다는 점에서는 JSON과 비슷하다.

하지만 문자열 형태의 JSON을 그대로 보관하는 방식이 아니다.

DuckDB가 데이터 안의 공통 구조를 자동으로 찾아 내부적으로 분해해 저장한다.

덕분에 별도의 스키마를 미리 정의하지 않아도 압축과 쿼리 실행 효율을 높일 수 있다.

예를 들어 다음과 같이 사용할 수 있다.

CREATE TABLE events (
    payload VARIANT
);

INSERT INTO events
VALUES (
    '{"user":{"id":42,"tags":["a","b"]}}'
    ::JSON::VARIANT
);

특히 구조가 조금씩 변하는 로그 데이터나 이벤트 스트림 같은 데이터에 어울리는 기능이다.

DuckDB 팀은 v2.0 이후 일반 JSON 타입의 내부 구현을 VARIANT 기반으로 바꾸는 것도 검토하고 있다고 밝혔다. 다만 이는 v2.0 이후 계획이며 확정 일정은 아니다.

---

4. 드디어 Trigger가 들어왔다

서버형 데이터베이스에 가까워지면서 자연스럽게 추가된 기능도 있다.

바로 Trigger다.

DuckDB 2.0은 다음 기능들을 제공할 예정이다.

BEFORE / AFTER

FOR EACH ROW / FOR EACH STATEMENT

OLD / NEW TABLE

여러 Trigger

RETURNING

DROP TRIGGER

등이다.

예를 들어 데이터가 변경될 때 자동으로 Audit Log를 남길 수 있다.

UPDATE
   │
   ▼
Target Table
   │
 Trigger
   ▼
Audit Table

예전 DuckDB가 단발성 분석 작업 중심이었다면, Trigger는 장시간 동작하는 DuckDB 서비스라는 새로운 사용 방식과 상당히 잘 맞는다.

---

5. AI 시대에 재미있는 기능, NEAREST JOIN

개인적으로 DuckDB 2.0의 SQL 변화 중 눈에 띄는 것은 NEAREST JOIN이다.

예를 들어 사용자 embedding과 상품 embedding이 있다고 해보자.

SELECT
    q.user_id,
    t.product_id
FROM users q
INNER JOIN products t
APPROX NEAREST 2
BY SIMILARITY
array_cosine_similarity(
    q.embedding,
    t.embedding
);

SQL JOIN 문법 자체로 Top-K Similarity Search를 수행할 수 있다.

기존에는 이런 작업을 위해 별도의 Vector DB나 검색 시스템을 고려해야 하는 경우가 많았다.

물론 이것만으로 DuckDB가 전문 Vector Database를 대체한다고 말할 수는 없다.

하지만 작은 AI 서비스나 로컬 RAG, 데이터 분석 파이프라인처럼

Metadata
+
Embedding
+
Analytics

를 한곳에서 처리하려는 상황에서는 꽤 흥미로운 선택지가 될 수 있다.

---

6. SQL 자체도 훨씬 강력해졌다

DuckDB 2.0에서는 SQL 기능도 대거 추가된다.

예를 들어 CTE 안에서 DELETE를 실행한 뒤 바로 다른 테이블로 넣을 수 있다.

WITH moved AS MATERIALIZED (
    DELETE FROM staging
    RETURNING *
)

INSERT INTO archive
SELECT *
FROM moved;

이외에도

• Nested Schema
• $variable 문법
• json_set
• json_insert
• json_replace
• json_remove
• Recursive CTE의 USING KEY
• SQL 표준 FETCH FIRST
• UNNEST in GROUP BY

등이 추가되거나 개선된다.

SQL 하나만으로 데이터 처리 파이프라인을 구성할 수 있는 영역이 조금씩 넓어지는 모습이다.

---

7. S3를 많이 쓴다면 Async I/O가 중요하다

현대 데이터 분석 환경에서는 데이터가 로컬 디스크보다 S3 같은 Object Storage에 존재하는 경우가 많다.

S3
 │
 ├─ parquet
 ├─ parquet
 ├─ parquet
 └─ parquet
      │
      ▼
    DuckDB

DuckDB는 이전에도 S3 데이터를 병렬로 읽을 수 있었다.

하지만 I/O 자체는 동기식 접근이라는 제약이 있었다.

DuckDB 2.0에서는 엔진 전반에 Asynchronous I/O가 도입된다.

이에 따라 I/O 처리와 Query Processing이 독립적으로 확장될 수 있다.

공식 설명에서도 로컬 저장장치보다는 특히 네트워크 스토리지에서 더 큰 효과를 기대할 수 있다고 설명한다.

지원 범위도 Parquet에서 시작해 CSV와 DuckDB 자체 파일 포맷으로 확대되고 있으며, 비동기 Parquet 쓰기도 포함된다.

[Inference] S3 + Parquet 기반 분석 파이프라인을 사용하는 개발자라면 DuckDB 2.0에서 가장 체감하기 쉬운 변화 중 하나가 될 가능성이 높다.

---

8. 쿼리 엔진도 상당히 빨라졌다

DuckDB 2.0에서는 기존 SQL을 수정하지 않아도 성능 향상을 얻을 수 있도록 Optimizer와 Execution Engine에도 많은 변경이 들어갔다.

대표적으로

• Join 아래로 Partial Aggregate Pushdown
• 중복 Aggregate 재사용
• Recursive CTE Engine 재작성
• 메모리 초과 Aggregate의 Disk Spill
• Partition-aware Query Planning
• Row Group Pruning 확대

등이다.

공식 블로그의 한 마이크로 벤치마크가 재미있다.

100만 개 Edge를 대상으로 Recursive CTE를 실행한 테스트다.

버전실행시간

DuckDB 1.5.4	4.90초
DuckDB 2.0 Preview	0.12초

약 40배 차이다.

다만 이는 특정 Recursive CTE 마이크로벤치마크 결과이므로 DuckDB 2.0의 모든 쿼리가 40배 빨라진다는 뜻은 아니다.

---

9. Storage Format도 2.0으로 바뀐다

DuckDB 2.0에서는 기본 Storage Format도 v2.0.0으로 변경된다.

변화는 꽤 내부적이지만 실제 운영에서는 중요하다.

Column Metadata를 Lazy Loading 방식으로 변경하고,

DICT_FSST 문자열 압축을 기본으로 사용하며,

Delete 정보를 더 작게 저장한다.

또 데이터를 읽을 때 Corruption Validation도 강화된다.

DuckDB 팀의 설명에 따르면 특히 큰 Index와 매우 많은 Column을 가진 Table을 열 때 로딩 속도와 메모리 사용량이 개선된다.

---

10. PostgreSQL Parser와도 작별한다

DuckDB는 오랫동안 PostgreSQL에서 파생된 SQL Parser를 사용했다.

DuckDB 2.0에서는 이것도 바뀐다.

자체 개발한 PEG 기반 SQL Parser가 도입된다.

사용자 입장에서 SQL 문법이 갑자기 달라지는 것은 아니다.

호환성을 유지하는 것이 목표다.

하지만 내부적으로는 꽤 중요한 변화다.

특히 Extension이 SQL Grammar 자체에 개입할 수 있게 된다.

[Inference] 장기적으로는 DuckDB Extension이 단순한 함수 추가 수준을 넘어 새로운 SQL 문법 자체를 제공하는 형태까지 확장될 가능성이 있다.

---

11. Extension 생태계도 크게 달라진다

DuckDB Extension 개발에는 한 가지 번거로운 문제가 있었다.

DuckDB 버전이 바뀌면 Extension을 다시 빌드해야 하는 경우가 많았다는 것이다.

DuckDB 2.0에서는 C API가 크게 정비된다.

그리고 상당 부분에 Stable ABI를 제공할 계획이다.

구조는 대략 다음과 같다.

My Extension
      │
      ▼
Stable C ABI
      │
      ▼
DuckDB
1.x → 2.x → ...

Extension 개발자가 DuckDB 릴리스마다 Extension을 다시 맞춰 빌드해야 하는 부담을 줄이는 것이 목표다.

Rust 기반 Extension을 위한 binding도 작업 중이다.

또 하나 재미있는 기능이 있다.

기업이나 개발자가 자신의 Extension Repository를 직접 운영할 수 있게 된다.

CREATE EXTENSION REPOSITORY my_repo
FROM 'https://extensions.example.org';

INSTALL my_ext
FROM my_repo;

RSA Public Key를 이용해 Extension을 검증하는 구조도 함께 제공될 예정이다. 해당 기능은 공식 프리뷰 게시 시점에는 일부가 개발 중이라고 명시되어 있다.

기업 내부 DuckDB Extension Store 같은 것도 가능해지는 셈이다.

---

결국 DuckDB 2.0에서 가장 중요한 변화는 무엇일까

기능 하나만 고르라면 Quack이나 Async I/O일 수도 있다.

하지만 더 중요한 것은 DuckDB의 포지션 변화라고 생각한다.

예전의 DuckDB를 단순화하면 이랬다.

Application
    │
    ▼
 DuckDB
    │
    ▼
Local File

DuckDB 2.0이 그리고 있는 그림은 상당히 다르다.

                ┌─ PostgreSQL
                │
Application ─ DuckDB ─ MySQL
                │
                ├─ S3 / Parquet
                │
                ├─ DuckLake
                │
                └─ Remote DuckDB

여기에

JSON / VARIANT
Vector Similarity
Trigger
Extension
Async I/O

까지 들어간다.

[Inference] 이런 방향이 이어진다면 DuckDB는 단순한 Embedded Analytics Database를 넘어 애플리케이션과 여러 데이터 저장소 사이에 놓이는 경량 분석 엔진이라는 역할을 더 강하게 가져갈 가능성이 있다.

그렇다고 PostgreSQL이나 MySQL을 대체하는 데이터베이스가 된다고 단정하기에는 이르다.

오히려 흥미로운 점은 기존 데이터베이스를 없애려 하기보다 연결하려 한다는 것이다.

PostgreSQL은 그대로 두고,

데이터는 S3에 그대로 두고,

Parquet도 그대로 둔다.

그리고 필요한 순간 DuckDB가 그 위에서 SQL을 실행한다.

---

AI 개발자에게 DuckDB 2.0이 흥미로운 이유

최근 AI 서비스를 만들다 보면 데이터 구조가 꽤 복잡해진다.

사용자 데이터 → PostgreSQL

로그 → JSON

분석 데이터 → Parquet / S3

Embedding → Vector

AI 결과 → JSON

실험 데이터 → CSV

예전에는 각각 다른 도구를 붙이는 것이 자연스러웠다.

[Inference] DuckDB 2.0의 여러 기능을 조합하면 일부 규모의 시스템에서는 이 데이터들을 하나의 SQL 분석 계층에서 다루는 아키텍처를 고려해볼 수 있다.

특히

S3 + Parquet + PostgreSQL + JSON + Embedding

조합을 사용하는 개발자라면 DuckDB 2.0은 꽤 주목할 만하다.

---

DuckDB는 더 이상 단순한 '작은 DB'만은 아니다

DuckDB 2.0 프리뷰를 읽으면서 가장 인상적이었던 부분은 기능의 개수가 아니었다.

방향이었다.

DuckDB는 여전히 가볍게 사용할 수 있는 In-process Database라는 장점을 유지하려 한다.

그러면서 동시에

Server

Remote Query

Object Storage

Lakehouse

Semi-structured Data

Vector Search

Extension Ecosystem

영역까지 조금씩 확장하고 있다.

공식 로드맵에도 Quack 안정화, Async I/O, Rust Extension 지원, Iceberg·Delta·Lance·DuckLake 개선 등이 포함되어 있다. 다만 로드맵 항목은 변경될 수 있으며 특정 시점 출시가 보장된 것은 아니다.

DuckDB 2.0의 정식 버전은 2026년 가을 출시가 예정되어 있다. 정확한 세부 기능과 Breaking Changes는 정식 Release Announcement에서 다시 확인할 필요가 있다.

하지만 방향만큼은 꽤 명확해 보인다.

DuckDB는 파일을 분석하는 작은 SQL 엔진에서, 데이터가 있는 곳으로 직접 찾아가는 SQL 엔진으로 확장되고 있다.