지난주에 딱 이런 게 있었으면 했는데, 타이밍이 절묘함
Deno 서버로 센서 값을 DuckDB에 흘려 넣고 있었는데, 서버를 내리지 않고는 duckdb -ui로 데이터를 확인할 수 없었음
DB 내용을 보기 위해 서버에 기능을 붙이고 싶지는 않아서 당분간 그냥 살려고 했는데, 이게 그 문제와 DuckDB에서 겪던 비슷한 문제들을 깔끔하게 해결해 줌
DuckDB는 2025/26년에 가장 좋아하는 기술이고, LLM 작업, 데이터 저장, 분석, 데이터 파이프라인 등 여러 워크플로에 깊이 들어와 있음
워크플로에서 어떻게 쓰는지 더 자세히 듣고 싶음
관심은 많은데 아직 문제 해결 방식에 DuckDB를 자연스럽게 끼워 넣지 못해서, 어떤 사용 사례에 매핑할 수 있을지도 잘 모르겠음
멋짐. 회사 내부 앱 프레임워크에 DuckDB를 써볼까 보고 있었는데, 이게 “그럼 수평 확장은 어떻게 하지” 문제를 해결해 줬음
DuckDB 팀에 박수를 보내고, 프로토콜 이름이 Quack인 것도 마음에 듦
관측성 데이터, 즉 지표·로그·트레이스를 Parquet에 저장하고 질의하는 오픈소스 프로젝트를 하고 있었고, 개방형 저장 포맷과 카탈로그를 쓰고 싶다는 데는 강하게 동의하지만 Apache Iceberg의 사용성에는 답답함이 있었음
이걸 보니 DuckLake가 내 사용 사례에 훨씬 더 흥미로워졌고, 앞으로 어디로 갈지 기대됨 https://github.com/smithclay/duckdb-otlp
Mimir를 대체하려고 쓰는 건지 궁금함
DuckDB는 좋지만 무엇이 되려는지 잘 모르겠음
쓰는 방식이 계속 새로 나오고, 어떤 방식이 맞는지 한눈에 보기 쉽지 않음
DuckDB는 독립 실행형이면서 동시에 구성 요소이기도 함
이번 시도는 꽤 일관적이고, 전통적인 클라이언트-서버 관계형 데이터베이스라는 익숙한 사용 모델로 되돌려 놓는 면이 있음
관계형 DBMS는 원래 다중 사용자 동시성 시스템이었고, DuckDB는 다른 시스템에 임베드할 수 있어서 다양한 사용 사례를 갖는 매우 빠른 로컬 엔진임
SQLite가 무엇이 되고 싶냐고 묻는 것과 비슷함. 휴대폰, 브라우저, 데스크톱 앱, IoT 기기에 들어가 있고 사람들이 여러 방향으로 확장해 왔음. 차이는 여기서는 서드파티가 아니라 퍼스트파티라는 점이고, 내겐 아주 이해하기 쉬운 움직임
자신에게 맞는 방식을 찾으면 됨
우리 데이터 파이프라인은 앱이 다운로드하는 .duckdb 파일을 생성함
앱은 S3의 자산을 감시하다가 etag가 바뀌면 가져옴
BigQuery나 ClickHouse 같은 성능을, 그 인프라를 직접 운영하거나 비용을 내지 않고도 얻기 쉬움
모든 경우에 완벽하진 않지만 예상보다 훨씬 많은 것을 처리함
이건 “DuckDB가 Postgres가 되려 한다”기보다, 더 큰 워크플로 안의 실행 계층이 되어 가는 것으로 읽힘
이제 엔진 자체가 항상 아픈 부분은 아니고, 주변부가 문제임. 라이브 DB, S3 경로, Parquet 파일, 자격 증명, 반복 가능한 실행, 내보내기, 검증, 그리고 일회성 스크립트가 조용히 인프라가 되는 순간들임
Quack은 원격/서버 부분을 더 깔끔하게 만들지만, 더 큰 흐름은 DuckDB가 최종 사용자용 도구라기보다 도구 내부의 SQL 계층이 되어 가는 쪽으로 보임
이 용도와 Arrow Flight의 사용 사례는 데이터 이동 말고는 많이 떠오르지 않음
“동시 작성자”가 뭔지 설명하지 않았음
보기엔 그냥 서버 쪽에서 쓰기를 직렬화하는 것 같음
그건 아닌 것 같음. DuckDB는 이미 한 프로세스 안에서 동시 쓰기를 지원함
이 기능이 갑자기 모든 쓰기를 직렬화할 이유가 보이지 않음
공유 팀 서버에 올려두고 싶은 작은 내부 분석 데이터셋에는 유용해 보임
홈랩 용도로도 충분히 살펴볼 만함
DuckLake와 함께 쓰면 멀티 테라바이트 데이터셋까지 잘 확장됨
이 서버 프로토콜의 큰 장점은 메모리가 큰 서버를 공유하고 최근 데이터에 대한 공유 캐시를 활용할 수 있다는 점임
C++ 애플리케이션이 있고, 실행 중에는 모든 것이 메모리에 있음
세션 사이에는 XML로 디스크에 저장하며 잘 동작하지만, 엄격히 단일 사용자용이고 몇몇 고객은 여러 사용자가 동시에 읽고 쓰도록 일반화하길 원함
성능 요구는 낮아서 2~3명이 동시에 몇천 건 정도를 갱신하는 수준임. 이런 경우 DuckDB + Quack이 좋은 선택일까? 아니면 더 나은 선택지가 있을까? SQLite도 봤지만 클라이언트-서버로 동작하지 않는다고 이해하고 있음
https://firebirdsql.org는 수십 년 동안 SQLite와 본격적인 PostgreSQL 사이에서 조용히 존재해 왔지만, 어떤 클라이언트-서버 데이터베이스를 쓸지 묻는다면 기본 추천은 PostgreSQL임
DuckDB는 분석 쪽에 더 가까움
동시 사용자를 처리하는 DB를 서버 쪽에 어떤 방식으로든 호스팅하지 않고 쓰기 좋은 선택지는 찾기 어려울 것 같음
물론 일부 게임이 직접 멀티플레이어용 클라이언트 서버를 만드는 것처럼 가능은 하지만, 솔직히 Postgres나 SQLite를 호스팅하는 건 터무니없이 싸고 쉽고, 무엇보다 이 문제에 대한 표준적인 접근임
CRDT에 잘 맞는 사용 사례처럼 들리고, 오프라인 편집도 가능해짐
검색해야 할 용어는 로컬 우선(local-first) 인 것 같음
훌륭함. DuckDB를 써서 Excel 같은 열 지향 스프레드시트 앱을 만들고 있었는데, 전통적인 HTTP 계층으로 “클라이언트”를 다시 만들어야 했음
“DuckDB가 무엇이 되고 싶어 하느냐”는 질문이 계속 나오지만, 답은 이미 분명하다고 봄
분석용 SQLite가 되고 싶은 것임. 임베드 가능하고, 설정이 필요 없고, 어디서나 동작함
Quack은 그 “어디서나”에 원격을 포함시키는 부분일 뿐임
DuckDB 팀이 직접 만든 쿡북이 있으면 아주 좋을 것 같음
“Quack과 함께 DuckDB를 DuckLake의 카탈로그 데이터베이스로 쓸 수 있나요?”에 대해 “아직은 아니지만 작업 중입니다!”라고 되어 있음
틈새 사용 사례처럼 보이지만 내가 가장 관심 있는 부분임
우리 레이크하우스는 DuckLake를 쓰고 카탈로그는 Postgres를 쓰는데, DuckDB / Quack 카탈로그가 훌륭한 대안이 될 것 같음
앞으로 Quack이 DuckLake 카탈로그의 주 옵션이 될 것 같음
이유는 여러 가지임. 첫째, 인라인 처리에서 타입 불일치가 없음. DuckDB가 아닌 카탈로그를 쓰면 많은 타입이 1:1로 매핑되지 않아 해당 데이터 타입을 다룰 때 추가 오버헤드가 생김
둘째, 카탈로그 위에서 DuckDB 분석 성능과 이제 트랜잭션 성능까지 그대로 얻을 수 있음. DuckDB가 DuckDB를 읽는 것이 우리 Postgres/SQLite 스캐너보다 단순히 더 빠름
셋째, 재시도를 위한 왕복이 없음. 전체 재시도 로직을 DuckDB 서버 쪽에서 쉽게(tm) 실행할 수 있음. 지금은 이런 재시도가 Postgres에 여러 번 왕복을 발생시켜 경합이 큰 작업부하에서 성능 병목이 됨
참고로 duckdb/ducklake 개발자임
Hacker News 의견들
지난주에 딱 이런 게 있었으면 했는데, 타이밍이 절묘함
Deno 서버로 센서 값을 DuckDB에 흘려 넣고 있었는데, 서버를 내리지 않고는
duckdb -ui로 데이터를 확인할 수 없었음DB 내용을 보기 위해 서버에 기능을 붙이고 싶지는 않아서 당분간 그냥 살려고 했는데, 이게 그 문제와 DuckDB에서 겪던 비슷한 문제들을 깔끔하게 해결해 줌
DuckDB는 2025/26년에 가장 좋아하는 기술이고, LLM 작업, 데이터 저장, 분석, 데이터 파이프라인 등 여러 워크플로에 깊이 들어와 있음
관심은 많은데 아직 문제 해결 방식에 DuckDB를 자연스럽게 끼워 넣지 못해서, 어떤 사용 사례에 매핑할 수 있을지도 잘 모르겠음
멋짐. 회사 내부 앱 프레임워크에 DuckDB를 써볼까 보고 있었는데, 이게 “그럼 수평 확장은 어떻게 하지” 문제를 해결해 줬음
DuckDB 팀에 박수를 보내고, 프로토콜 이름이 Quack인 것도 마음에 듦
관측성 데이터, 즉 지표·로그·트레이스를 Parquet에 저장하고 질의하는 오픈소스 프로젝트를 하고 있었고, 개방형 저장 포맷과 카탈로그를 쓰고 싶다는 데는 강하게 동의하지만 Apache Iceberg의 사용성에는 답답함이 있었음
이걸 보니 DuckLake가 내 사용 사례에 훨씬 더 흥미로워졌고, 앞으로 어디로 갈지 기대됨
https://github.com/smithclay/duckdb-otlp
DuckDB는 좋지만 무엇이 되려는지 잘 모르겠음
쓰는 방식이 계속 새로 나오고, 어떤 방식이 맞는지 한눈에 보기 쉽지 않음
이번 시도는 꽤 일관적이고, 전통적인 클라이언트-서버 관계형 데이터베이스라는 익숙한 사용 모델로 되돌려 놓는 면이 있음
관계형 DBMS는 원래 다중 사용자 동시성 시스템이었고, DuckDB는 다른 시스템에 임베드할 수 있어서 다양한 사용 사례를 갖는 매우 빠른 로컬 엔진임
SQLite가 무엇이 되고 싶냐고 묻는 것과 비슷함. 휴대폰, 브라우저, 데스크톱 앱, IoT 기기에 들어가 있고 사람들이 여러 방향으로 확장해 왔음. 차이는 여기서는 서드파티가 아니라 퍼스트파티라는 점이고, 내겐 아주 이해하기 쉬운 움직임
앱은 S3의 자산을 감시하다가 etag가 바뀌면 가져옴
BigQuery나 ClickHouse 같은 성능을, 그 인프라를 직접 운영하거나 비용을 내지 않고도 얻기 쉬움
모든 경우에 완벽하진 않지만 예상보다 훨씬 많은 것을 처리함
이제 엔진 자체가 항상 아픈 부분은 아니고, 주변부가 문제임. 라이브 DB, S3 경로, Parquet 파일, 자격 증명, 반복 가능한 실행, 내보내기, 검증, 그리고 일회성 스크립트가 조용히 인프라가 되는 순간들임
Quack은 원격/서버 부분을 더 깔끔하게 만들지만, 더 큰 흐름은 DuckDB가 최종 사용자용 도구라기보다 도구 내부의 SQL 계층이 되어 가는 쪽으로 보임
“동시 작성자”가 뭔지 설명하지 않았음
보기엔 그냥 서버 쪽에서 쓰기를 직렬화하는 것 같음
이 기능이 갑자기 모든 쓰기를 직렬화할 이유가 보이지 않음
공유 팀 서버에 올려두고 싶은 작은 내부 분석 데이터셋에는 유용해 보임
홈랩 용도로도 충분히 살펴볼 만함
이 서버 프로토콜의 큰 장점은 메모리가 큰 서버를 공유하고 최근 데이터에 대한 공유 캐시를 활용할 수 있다는 점임
C++ 애플리케이션이 있고, 실행 중에는 모든 것이 메모리에 있음
세션 사이에는 XML로 디스크에 저장하며 잘 동작하지만, 엄격히 단일 사용자용이고 몇몇 고객은 여러 사용자가 동시에 읽고 쓰도록 일반화하길 원함
성능 요구는 낮아서 2~3명이 동시에 몇천 건 정도를 갱신하는 수준임. 이런 경우 DuckDB + Quack이 좋은 선택일까? 아니면 더 나은 선택지가 있을까? SQLite도 봤지만 클라이언트-서버로 동작하지 않는다고 이해하고 있음
동시 사용자를 처리하는 DB를 서버 쪽에 어떤 방식으로든 호스팅하지 않고 쓰기 좋은 선택지는 찾기 어려울 것 같음
물론 일부 게임이 직접 멀티플레이어용 클라이언트 서버를 만드는 것처럼 가능은 하지만, 솔직히 Postgres나 SQLite를 호스팅하는 건 터무니없이 싸고 쉽고, 무엇보다 이 문제에 대한 표준적인 접근임
훌륭함. DuckDB를 써서 Excel 같은 열 지향 스프레드시트 앱을 만들고 있었는데, 전통적인 HTTP 계층으로 “클라이언트”를 다시 만들어야 했음
“DuckDB가 무엇이 되고 싶어 하느냐”는 질문이 계속 나오지만, 답은 이미 분명하다고 봄
분석용 SQLite가 되고 싶은 것임. 임베드 가능하고, 설정이 필요 없고, 어디서나 동작함
Quack은 그 “어디서나”에 원격을 포함시키는 부분일 뿐임
“Quack과 함께 DuckDB를 DuckLake의 카탈로그 데이터베이스로 쓸 수 있나요?”에 대해 “아직은 아니지만 작업 중입니다!”라고 되어 있음
틈새 사용 사례처럼 보이지만 내가 가장 관심 있는 부분임
우리 레이크하우스는 DuckLake를 쓰고 카탈로그는 Postgres를 쓰는데, DuckDB / Quack 카탈로그가 훌륭한 대안이 될 것 같음
이유는 여러 가지임. 첫째, 인라인 처리에서 타입 불일치가 없음. DuckDB가 아닌 카탈로그를 쓰면 많은 타입이 1:1로 매핑되지 않아 해당 데이터 타입을 다룰 때 추가 오버헤드가 생김
둘째, 카탈로그 위에서 DuckDB 분석 성능과 이제 트랜잭션 성능까지 그대로 얻을 수 있음. DuckDB가 DuckDB를 읽는 것이 우리 Postgres/SQLite 스캐너보다 단순히 더 빠름
셋째, 재시도를 위한 왕복이 없음. 전체 재시도 로직을 DuckDB 서버 쪽에서 쉽게(tm) 실행할 수 있음. 지금은 이런 재시도가 Postgres에 여러 번 왕복을 발생시켜 경합이 큰 작업부하에서 성능 병목이 됨
참고로 duckdb/ducklake 개발자임
며칠 안에 테스트할 수 있게 될 것임