대규모 시계열 데이터를 위한 DB 엔진 8종 비교 — 2,200만 건 실측 벤치마크
수천만 건의 시계열 데이터를 저장하고 분석해야 한다면, 어떤 DB를 선택해야 할까요? IoT 센서 로그, 서버 메트릭, 실시간 트래픽, 시세 데이터 — 시간 축을 가진 대규모 데이터는 일반 RDBMS로는 한계가 분명합니다. 2,200만 건의 시계열 데이터를 기준으로 PostgreSQL+TimescaleDB, ClickHouse, QuestDB 등 8개 엔진을 동일한 조건에서 벤치마크했습니다. 집계 쿼리 속도는 25ms부터 3,493ms까지 140배 차이가 났습니다.
8종
비교 DB 엔진
140배
쿼리 속도 최대 차이
2,200만
테스트 데이터 행수
6가지
평가 기준 항목
왜 시계열 전용 DB인가
시계열 데이터는 일반 데이터와 근본적으로 다른 특성을 갖습니다. 시간순 삽입이 압도적이고, UPDATE보다 INSERT가 핵심이며, 시간 범위 기반 집계 쿼리가 대부분입니다. 일반 PostgreSQL에서 동일한 쿼리가 3,493ms 걸리던 것이 전용 엔진에서는 25ms로 줄어듭니다.
시계열 데이터의 특성
- • 쓰기 패턴: 시간순 Append-only가 99% 이상
- • 읽기 패턴: 시간 범위 기반 집계 (5분/1시간/1일 단위)
- • 데이터량: 초당 수만~수백만 행 수집 가능
- • 보존 정책: 오래된 데이터는 다운샘플링 or 삭제
- • 압축 효과: 시간 정렬된 데이터는 90%+ 압축 가능
일반 RDBMS의 한계
- • 행 기반 저장 → 집계 쿼리 시 불필요한 컬럼까지 스캔
- • B-tree 인덱스 → 시간 범위 스캔에 비효율적
- • VACUUM 부담 → 대량 INSERT 후 성능 저하
- • 압축 미지원 → 스토리지 비용 증가
- • 시간 기반 파티셔닝을 수동으로 관리해야 함
적용 분야 예시
서버 모니터링
CPU/메모리/디스크 메트릭
IoT/센서
온도·습도·진동 데이터
트래픽 분석
요청 수, 응답 시간, 에러율
시세/거래
가격 변동, 거래량 추이
테스트 환경과 평가 기준
2,200만 건의 시계열 데이터(타임스탬프 + 4개 수치 컬럼 + 거래량)를 기준으로, 시간 범위 집계 쿼리의 응답 속도를 측정했습니다. 성능 외에도 실무에서 중요한 6가지 기준을 100점 만점으로 평가했습니다.
데이터 스펙
- • 행 수: 2,200만 건
- • 컬럼: timestamp, open, high, low, close, volume
- • 시간 범위: 약 20년치 분봉~일봉 혼합
- • 원본 크기: ~4.2GB (CSV 기준)
벤치마크 쿼리
- • 시간 범위 집계 (5분/1시간/1일 버킷)
- • FIRST/LAST 값 추출
- • MAX/MIN/SUM 계산
- • 다중 종목 필터 + 집계
6가지 평가 기준
- • SQL 호환성: 표준 SQL 지원 수준
- • AI/ML 연동: Python·벡터·파이프라인 호환
- • 프론트엔드 속도: 대시보드 응답 시간
- • 생태계: 도구·드라이버·커뮤니티
- • 학습 용이성: 도입·운영 난이도
- • 확장성: 수평 확장·클러스터링
종합 순위표
집계 쿼리 성능, 수집 처리량, 압축률, 그리고 6가지 실무 평가 기준을 종합한 순위입니다. 100점 만점 기준으로 시계열 데이터 처리 + AI 파이프라인 + 프론트엔드 서빙을 모두 고려했습니다.
| # | DB 엔진 | 유형 | 집계 쿼리 | 수집 속도 | 압축률 | 종합 |
|---|---|---|---|---|---|---|
| 1 | PostgreSQL + TimescaleDB | 시계열 확장 RDBMS | 1,021ms | 22만 행/s | 90%+ | 92/100 |
| 2 | ClickHouse | 컬럼형 OLAP | 547ms | 100만+ 행/s | 95%+ | 85/100 |
| 3 | QuestDB | 전용 시계열 DB | 25ms | 400만+ 행/s | 85%+ | 73/100 |
| 4 | DuckDB | 임베디드 OLAP | ~500ms | 로컬 최적화 | Parquet | 68/100 |
| 5 | InfluxDB 3.0 | 전용 시계열 DB | N/A | 높음 | Arrow+Parquet | 55/100 |
| 6 | MongoDB | 문서형 NoSQL | 높음 | 중간 | WiredTiger | 45/100 |
| 7 | TDengine | IoT 시계열 DB | ~300ms | 높음 | 90%+ | 42/100 |
| 8 | Apache Druid | 실시간 OLAP | 빠름 | 높음 | 컬럼형 | 38/100 |
종합 점수는 6가지 평가 기준(SQL 호환성, AI 연동, 프론트엔드 속도, 생태계, 학습 용이성, 확장성)의 가중 평균입니다.
상위 3개가 차별화되는 이유
- • TimescaleDB(92점): PostgreSQL 호환성 + 시계열 최적화의 밸런스. 기존 인프라 활용 가능
- • ClickHouse(85점): 순수 분석 속도 최강. 수집 100만+ 행/s, 압축 95%+
- • QuestDB(73점): 집계 쿼리 25ms로 압도적이나, 생태계와 OLTP 기능이 부족
하위 엔진이 낮은 이유
- • MongoDB(45점): 시계열 전용이 아님. 문서 모델의 구조적 한계
- • TDengine(42점): IoT 특화로 범용성 부족, 커뮤니티 작음
- • Druid(38점): 운영 복잡도가 높고 소규모 팀에 비현실적
집계 쿼리 벤치마크
2,200만 건에서 시간 범위 집계 쿼리(시간 버킷별 OHLCV 집계)를 실행한 결과입니다. 동일한 쿼리 로직을 각 DB의 네이티브 문법으로 작성했습니다.
속도 차이가 이렇게 큰 이유
PostgreSQL (3,493ms)
- • 행 기반 저장 → 모든 컬럼 풀스캔
- • 시간 버킷 함수 없음 → 수동 date_trunc
- • 압축/파티셔닝 미적용 시 I/O 과다
QuestDB (25ms)
- • 컬럼형 저장 + 시간 파티셔닝 네이티브
- • SAMPLE BY 문법으로 집계 최적화
- • 메모리 매핑 I/O로 디스크 접근 최소화
쿼리 속도만으로 선택하면 안 되는 이유
QuestDB가 25ms로 가장 빠르지만, 종합 순위에서는 3위입니다. UPDATE/DELETE 미지원, JOIN 제한, 작은 생태계가 실무에서 큰 제약이 됩니다. 반면 TimescaleDB는 1,021ms로 40배 느리지만, PostgreSQL 전체 기능을 그대로 사용할 수 있고 Continuous Aggregates로 실시간 캐싱하면 실제 대시보드 응답은 수 ms 수준입니다.
엔진별 심층 비교
PostgreSQL + TimescaleDB
시계열 확장 RDBMS · Apache 2.0 + TSL
집계 쿼리
1,021ms
수집 속도
22만 행/s
압축률
90%+
종합 점수
92/100
강점
- • 기존 PostgreSQL 위에 확장 → 마이그레이션 최소
- • time_bucket(), FIRST(), LAST() 등 시계열 전용 함수
- • Continuous Aggregates로 실시간 집계 자동화
- • 90%+ 압축률로 스토리지 절약
- • pgvector 확장으로 AI 벡터 검색 가능
- • 모든 PostgreSQL 도구/드라이버 호환
약점
- • 순수 분석 쿼리 속도는 컬럼형 DB 대비 느림
- • 수평 확장(Multi-node) 지원 중단됨
- • TSL 라이선스 일부 기능 제한
추천 1순위: PostgreSQL을 이미 사용 중이라면 가장 자연스러운 업그레이드 경로
ClickHouse
컬럼형 OLAP DB · Apache 2.0
집계 쿼리
547ms
수집 속도
100만+ 행/s
압축률
95%+
종합 점수
85/100
강점
- • 분석 쿼리 속도 최강급 (TimescaleDB 대비 2배)
- • Materialized View로 자동 집계
- • 수평 확장 네이티브 지원
- • 압축률 95%+ (스토리지 비용 최소화)
- • 실시간 대시보드에 최적
- • 완전 무료 오픈소스 (Apache 2.0)
약점
- • UPDATE/DELETE 제한적 (OLTP 부적합)
- • PostgreSQL과 별도 운영 필요
- • 학습 곡선이 상대적으로 높음
- • 트랜잭션 미지원
분석 전용 2nd DB로 적합: 대규모 집계/대시보드가 핵심일 때
QuestDB
전용 시계열 DB · Apache 2.0
집계 쿼리
25ms
수집 속도
400만+ 행/s
압축률
85%+
종합 점수
73/100
강점
- • 시계열 집계 쿼리 속도 압도적 1위 (25ms)
- • ASOF JOIN 네이티브 지원 (시계열 데이터 핵심)
- • SAMPLE BY, LATEST ON 시계열 전용 SQL
- • N차원 배열 지원 (임베딩, 센서 배열)
- • PostgreSQL 와이어 프로토콜 호환
- • 완전 무료 (Apache 2.0)
약점
- • OLTP 기능 없음 (UPDATE/DELETE 미지원)
- • 생태계가 상대적으로 작음
- • JOIN 기능 제한적
- • 메타데이터 관리에 별도 DB 필요
읽기 전용 분석 레이어로 강력: 초고속 시계열 쿼리가 최우선일 때
DuckDB
임베디드 OLAP · MIT
강점
- • 설치 불필요 (
pip install duckdb) - • Parquet/CSV 직접 쿼리 가능
- • Python/Pandas 네이티브 통합
- • AI/ML 파이프라인에 최적
- • ASOF JOIN 지원
약점
- • 서버리스 → 동시 접속 불가
- • 프로덕션 서빙용 아님
- • 실시간 수집 부적합
- • 단일 머신에 한정
AI/ML 분석 보조 도구: 로컬 데이터 탐색·피처 엔지니어링 전용
InfluxDB 3.0
전용 시계열 DB · MIT / Apache 2.0
강점
- • 3.0에서 Rust 기반 완전 재설계
- • 무제한 카디널리티
- • SQL 기본 쿼리 언어로 전환
- • Arrow + Parquet 아키텍처
약점
- • Core 버전 72시간 보존 제한
- • Continuous Aggregate 미지원
- • 이전 버전과 호환성 없음
- • 아직 성숙하지 않은 엔진
IoT/모니터링 특화: 범용 시계열 분석에는 TimescaleDB 대비 이점 부족
6~8위 간략 비교
| DB | 포지션 | 적합한 경우 | 비추천 이유 |
|---|---|---|---|
| MongoDB | 문서형 NoSQL | 스키마 유동적인 로그 저장 | 집계 쿼리 느림, 시계열 최적화 부족 |
| TDengine | IoT 전용 시계열 | IoT 디바이스 대량 수집 | 커뮤니티 작음, SQL 호환성 낮음 |
| Apache Druid | 실시간 OLAP | 대규모 실시간 대시보드 | 운영 복잡도 극높음, 소규모 팀 부적합 |
추천 아키텍처 구성
단일 DB로 모든 것을 해결하려는 시도는 실패합니다. 수집, 저장, 분석, 서빙 각 레이어에 적합한 도구를 배치하는 것이 핵심입니다.
데이터 수집
다양한 소스에서 시계열 데이터를 주기적으로 수집
메인 저장소
시계열 데이터, 메타데이터, 사용자 데이터를 통합 관리
캐싱 레이어
최근 데이터 캐싱, API 응답 캐싱, 실시간 Pub/Sub
분석 레이어
대규모 배치 분석, 통계 처리, ML Feature 생성
AI/ML 레이어
예측 모델 학습, 임베딩 생성, 추론 파이프라인
API 레이어
프론트엔드와 AI 모듈에 데이터 서빙
프론트엔드
실시간 차트, 대시보드, 분석 결과 시각화
왜 멀티 DB인가?
단일 DB의 한계
- • TimescaleDB: 분석은 느림 → ClickHouse/DuckDB 병행
- • ClickHouse: OLTP 불가 → 메타데이터용 PostgreSQL 필요
- • QuestDB: JOIN 제한 → 복합 쿼리에 부적합
권장 조합
- • 소규모: TimescaleDB 단독 (충분)
- • 중규모: TimescaleDB + DuckDB (분석 보조)
- • 대규모: TimescaleDB + ClickHouse + Redis
용도별 선택 가이드
범용 시계열 저장
CRUD + 시계열 집계를 하나의 DB로 처리해야 할 때. 기존 PostgreSQL 인프라 활용 가능.
추천: TimescaleDB
종합 92점. SQL 100% 호환, pgvector로 AI 확장.
대규모 분석/대시보드
수억 건 이상의 데이터에서 실시간 집계 대시보드를 서빙해야 할 때.
추천: ClickHouse
547ms 집계, 100만 행/s 수집, 95% 압축.
초저지연 시계열 쿼리
밀리초 단위 응답이 필요한 실시간 모니터링, 트레이딩 시스템.
추천: QuestDB
25ms 집계. ASOF JOIN 네이티브. 읽기 전용 레이어.
ML/AI 파이프라인
Python 환경에서 데이터 탐색, 피처 엔지니어링, 모델 학습.
추천: DuckDB
pip install 한 줄. Parquet 직접 쿼리. Pandas 통합.
IoT 센서 대량 수집
수만 디바이스에서 초당 수백만 포인트가 쏟아지는 환경.
추천: TimescaleDB 또는 TDengine
TimescaleDB가 범용성 우위. TDengine은 IoT 초특화.
피해야 할 실수
- • 일반 PostgreSQL로 버티기: 데이터가 수백만 건을 넘으면 집계 쿼리가 급격히 느려집니다. TimescaleDB 확장만 추가해도 3.4배 빨라집니다.
- • 벤치마크 속도만 보고 선택: QuestDB가 25ms로 가장 빠르지만, UPDATE가 안 되고 JOIN이 제한적입니다. 실무에서는 종합적인 기능이 더 중요합니다.
- • InfluxDB 2.x에서 3.0 마이그레이션 기대: 완전히 다른 엔진입니다. 기존 Flux 쿼리를 SQL로 재작성해야 합니다.
- • MongoDB를 시계열 DB로 사용: Time Series Collections이 있지만, 전용 엔진 대비 집계 성능이 크게 뒤떨어집니다.
결론
대규모 시계열 데이터 처리에서 “만능 DB”는 없습니다. 핵심은 메인 저장소 + 분석 레이어를 분리하는 것입니다.
- 메인 저장소: PostgreSQL + TimescaleDB (종합 92점, SQL 100% 호환)
- 분석 가속: ClickHouse 또는 DuckDB를 용도에 맞게 병행
- 초저지연: QuestDB를 읽기 전용 레이어로 배치
- 캐싱: Redis로 프론트엔드 응답 속도를 ms 단위로 유지
스토리지 인프라의 성능은 DB 엔진 선택만으로 결정되지 않습니다. NVMe 3-Tier 스토리지 전략에서 물리 디스크 배치까지 포함한 종합 설계를 확인할 수 있고, NVMe 20개 벤치마크에서 실제 디바이스별 I/O 성능 차이를 비교할 수 있습니다.
댓글
(4개)로그인하면 댓글을 작성할 수 있습니다.
8개 DB를 동일 조건으로 비교한 자료가 귀합니다. TimescaleDB가 종합 1위라는 건 기존 PostgreSQL 사용자에게 안심이 되네요. ClickHouse를 분석 전용으로 병행하는 전략이 현실적입니다.
QuestDB의 25ms 쿼리 속도가 놀랍습니다. ASOF JOIN 같은 시계열 전용 SQL이 있는 건 몰랐네요. 실시간 대시보드 용도로 검토해봐야겠습니다.
DuckDB를 ML 파이프라인에서만 쓰고 있었는데, 다른 DB와의 포지셔닝이 명확해졌습니다. 프로덕션 서빙이 아니라 분석 보조라는 역할 정의가 정확합니다.
관련 글
© 2026 TreeRU. All rights reserved.
본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.