PostHog, 고객용 데이터 웨어하우스를 DuckDB에서 Trino·HogLake로 재설계
PostHog는 고객용 데이터 웨어하우스의 실행 기반을 Trino와 HogLake로 재구성했습니다. 단일 노드 DuckDB는 대형 쿼리에 필요한 자원을 미리 잡아야 했고, DuckLake의 카탈로그 커밋은 전체 통계를 읽느라 느려졌습니다. ClickHouse는 주력 제품 분석에 계속 쓰이며 새 구성은 PostHog 규모에서 시험 중입니다.
최신기사
AI, 개발 도구, 오픈소스, 보안과 인프라의 변화와 이용 조건을 설명하는 최신 기사와 해설입니다.
Jepsen, ParticleDB 여러 버전서 96개 이슈 발견, rc22에도 쓰기 손실
Jepsen은 ParticleDB 1.1.4부터 1.1.18.11.rc-22까지의 시험에서 SQL 오류와 트랜잭션 이상, 데이터 손실 등 96개 이슈를 기록했습니다. Orkes는 1.1.19-rc.13에서 남은 문제를 해결했다고 밝혔지만 Jepsen은 이후 버전을 시험하지 않았으며, 공식 문서상 최신 빌드는 1.1.19-rc.16입니다.
MariaDB, InnoDB LRU 승격 경로 수정해 일부 시험서 11.8 처리량 2.8배 높여
MariaDB가 InnoDB의 페이지 승격 과정에서 발생하던 전역 뮤텍스 경합을 줄이는 패치를 11.8 브랜치에 병합했습니다. 40스레드·100GiB 버퍼 풀의 읽기 중심 시험에서 11.8 처리량은 수정 전 20,326 QPS에서 수정안 57,052 QPS로 증가했습니다. 특정 벤치마크 결과이며 혼합 읽기·쓰기 작업은 후속 측정 과제로 남았습니다.
GROUP BY가 더 많은 연산을 하고도 빨라진 이유
Pivotlake는 99m행 데이터의 UserID 집계를 4096개 파티션으로 나눠 처리한 실험을 공개했습니다. 단일 코어 비교에서 메모리 대기와 DRAM 읽기가 줄었고, 재실행 시간은 약 3.6초에서 약 2.7초로 짧아졌습니다.
DuckDB.NET 1.5.6.1, 데이터 읽기 최대 12배 빨라져
DuckDB.NET 1.5.6.1은 DuckDB 엔진을 그대로 둔 채 .NET 데이터 리더의 형식 변환과 호출 경로를 개선했습니다. 벤치마크에서 읽기 작업이 최대 12배 빨라졌고, 정수 열을 double로 읽을 때 할당량은 366MB에서 18KB로 줄었습니다.
Valkey 9.2의 RDB LZ4 압축, 100만 건 파일을 178MB에서 35MB로 줄여
Valkey 9.2.0-rc1에서 전체 RDB 스트림을 LZ4로 압축하자 반복 구조가 있는 데이터의 파일 크기가 약 80% 줄었습니다. 다만 데이터 종류에 따라 효과가 달랐고, 복제 압축 설정과 릴리스 노트 해석은 작성자가 댓글에서 정정·재검증하기로 했습니다.
SQLite 3.54의 .diskused는 빌드 플래그가 필요합니다. sqlite3_analyzer에는 필요하지 않았습니다
SQLite 3.54는 별도 도구 sqlite3_analyzer를 대체하는 셸 명령 .diskused를 추가했습니다. 같은 데이터베이스 분석에서 평균 실행 시간이 약 2.4배 빨랐지만, SQLITE_ENABLE_DBSTAT_VTAB 없이 빌드하면 오류 없이 아무것도 출력하지 않습니다. 댓글에서는 장시간 분석이 롤백 저널 모드의 쓰기 커밋을 막을 수 있다는 점도 확인했습니다.
분산 시스템에는 ‘지금’이 없습니다
분산 시스템에서는 서버 시각만으로 동시 쓰기의 순서를 정할 수 없습니다. 글은 Lamport의 happens-before 관계를 바탕으로 시계 대신 인과관계를 추적하는 방법을 설명하고, Last Write Wins, 버전 벡터, CRDT를 비교합니다.
분산 SQLite의 12년
rqlite 개발자가 2014년부터 이어진 분산 SQLite 프로젝트의 역사를 되짚으며 합의, WAL 스트리밍, 데이터 병합이라는 세 설계 방향을 구분합니다. 각 방식은 장애 복구와 일관성, 다중 쓰기 중 무엇을 해결하려는지에 따라 쓰임이 달라집니다.
pgrust를 ClickBench에서 제외해야 합니다: 제출물이 벤치마크 규칙을 어겼습니다
ClickBench의 pgrust 0.4-preview 제출물에 쿼리별 최적화 코드와 결과 재사용 캐시가 포함됐다는 이유로 제외 요청이 제기됐습니다. pgrust 제작자는 해당 코드는 실행되지 않았고 캐시는 사전 계산 결과가 아닌 중간 데이터용이라며 반박했지만, 제한된 SQL 지원 상태로 제출한 점은 인정했습니다.
UUIDv7은 생각만큼 많은 속성을 보장하지 않습니다
UUIDv7은 생성 시각을 담고 대체로 정렬되지만, 정확한 시각이나 엄격한 단조 증가를 보장하지 않습니다. 시계가 역행할 때 Python 구현의 타임스탬프가 실제 시각보다 계속 앞서가는 사례를 보이고, 구현별 보장과 전제 조건을 확인하라고 제안합니다.
Redis 8.4의 digest 기반 SET, 1MB 비교 후 쓰기 지연을 4.4ms에서 1.8ms로 줄여
Redis 8.4의 SET 조건부 옵션 IFEQ와 IFDEQ는 기존 값이나 digest가 일치할 때만 쓰기를 수행합니다. 작성자의 localhost 측정에서 1MB 값에 IFDEQ를 쓰면 기존 GET-후-SET보다 지연이 줄었고, 동시 갱신 실험에서는 재시도 루프로 lost update를 막았습니다. 다만 값의 동일성만 비교하므로 WATCH와 의미가 다를 수 있습니다.
DuckDB 2.0.0 LTS “Cinnamon Teal” 출시
DuckDB 2.0.0 LTS는 비동기 I/O, VARIANT, 트리거, 확장 가능한 SQL 파서와 에이전트 모드를 추가한 기능 중심 릴리스입니다. 지원 기간은 2027년 10월까지이며, 데이터베이스 파일의 하위 버전 호환성과 운영 전 테스트 등 마이그레이션 조건도 함께 안내합니다.
PingCAP TiDB 유출 주장: 고객 접속 로그와 운영 정보 공개
FulcrumSec은 PingCAP의 TiDB Cloud 운영·재무·분석 시스템과 저장소를 침해해 10.6TB를 확보했다고 주장하며 200GB가 넘는 자료를 공개했습니다. 고객 데이터베이스 접속 정보와 자격 증명, 내부 보안 티켓 등이 포함됐다는 주장으로, 유출 범위와 실제 고객 데이터 영향은 별도 확인이 필요합니다.
DuckDB 2.0.0 LTS “Cinnamon Teal” 출시
DuckDB 2.0.0 LTS가 Quack 클라이언트-서버 연결, 비동기 I/O, VARIANT, 트리거, 확장 가능한 PEG 파서 등을 추가했습니다. 지원 기간은 최소 2027년 10월까지이며, 2.0에서 만든 데이터베이스 파일은 이전 버전으로 열 수 없으므로 업그레이드 전에 검증이 필요합니다.
Jepsen: Orkes Conductor 5.3.2 장애 내성 분석
Jepsen이 Orkes Conductor 5.3.2와 후속 버전을 장애 주입 테스트한 결과, 워크플로가 영구히 방치되거나 사라지고 실행되지 않은 채 완료 처리되는 안전성 문제가 확인됐습니다. Orkes는 주요 문제를 5.5.0과 5.5.6에서 수정했지만, 중복 태스크 실행과 클라이언트 오류 처리, 저장소의 내구성은 별도로 고려해야 합니다.
에이전트 재시도와 중단을 견디는 애플리케이션 상태 관리
에이전트의 재시도 문제는 모델의 추론보다 요청 결과가 불명확한 상황과 외부 부작용을 어떻게 기록·통제하느냐에 달려 있습니다. 세 글은 작업 의도와 멱등성 키, 애플리케이션이 소유하는 워크플로 상태, 독립적인 대사를 각각 다루며, 안전한 재시도에는 이 관리 방식들이 함께 필요하다고 설명합니다.
EmbodiWeave: 실패 기록을 읽고도 같은 선택을 반복한 에이전트, 그래프 규칙으로 선택을 제한하다
EmbodiWeave는 로봇 정책의 학습 시작점을 고르는 에이전트로, 체크포인트와 평가, 실패 기록을 FalkorDB 그래프에 저장하고 MCP로 조회합니다. 그래프가 과거 회귀 이력이 있는 계보를 후보에서 제외하자 에이전트의 선택이 달라졌지만, 새 정책도 부모보다 나빠 배포되지 않았습니다.
버그는 로직이 아니라 경계에서 발생합니다
HivePlane v0.2.0의 현장 테스트에서 메모리 테스트가 놓친 결함은 값이 데이터베이스나 API 경계를 넘을 때 드러났습니다. 글은 PostgreSQL을 포함한 실제 환경에서 경계 간 데이터 변환과 상태를 검증해야 한다고 설명하며, 댓글에서는 백업 복원 검사의 실제 스키마 확인이 빠졌다는 점을 짚습니다.
PostgreSQL 19 베타의 병렬 autovacuum, 작업자를 늘려도 vacuum 시간은 그대로
PostgreSQL 19 beta4는 autovacuum의 인덱스 정리에 병렬 작업자를 투입하는 설정을 추가합니다. 한 실험에서 autovacuum 작업자의 CPU 시간은 약 30% 줄었지만 전체 vacuum 시간은 약 4%만 짧아졌습니다. 이 결과는 heap 스캔이 병목인 작업에서는 병렬 인덱스 정리만으로 처리 시간이 줄지 않음을 보여줍니다.