LabHub

블로그

시계열 데이터베이스 2026 — TimescaleDB / InfluxDB 3 / QuestDB / ClickHouse / VictoriaMetrics 심층 비교

2026-05-15 · 29 분 읽기 · #time-series#database#tsdb#timescaledb#influxdb#questdb#clickhouse#victoriametrics#prometheus#mimir#greptimedb#m3db#deep-dive

한국어English日本語

프롤로그 — "시계열 DB 하나로 다 되는 시대는 끝났다"

2017년쯤만 해도 "시계열 DB?" 하면 InfluxDB 1.x 한 개의 이름이 떠올랐다. 2020년이 되자 Prometheus가 메트릭의 표준이 됐고, TimescaleDB가 Postgres 위에서 SQL을 무기로 등장했다. 2023년에는 ClickHouse가 OLAP 영역에서 시계열까지 잠식하기 시작했고, QuestDB는 Java로 빠른 ingest를 들고 나왔다.

2026년 현재, 우리가 "시계열 데이터"라 부르는 것 안에는 최소 4개의 다른 워크로드가 들어 있다.

  1. 메트릭 (metrics) — CPU·메모리·QPS 같은 시간당 숫자. 카디널리티 폭발이 핵심 적.
  2. 로그 (logs) — 텍스트 한 줄당 timestamp + 메시지. 풀텍스트 검색 + 시간 필터.
  3. 트레이스 (traces) — 분산 시스템의 span. span-id, trace-id로 연결된 그래프 구조.
  4. IoT/센서 (telemetry) — 디바이스·차량·공장 센서의 시계열. 압축률과 ingest 처리량.

이 4축 위에 또 OLAP(분석성 쿼리)와 APM(애플리케이션 성능 관리)이라는 응용 카테고리가 겹친다. 그래서 같은 "시계열 DB"라는 라벨을 달고 있어도 TimescaleDB와 VictoriaMetrics와 ClickHouse는 서로 노리는 시장이 다르다.

이 글은 2026년 5월 기준 9개 주요 후보 — TimescaleDB, InfluxDB 3 Core/Enterprise, QuestDB, ClickHouse, VictoriaMetrics, Prometheus + Grafana Mimir, M3DB, GreptimeDB, TDengine/OpenTSDB — 의 위치와 강점·약점을 정리한다. 그리고 마지막에 "우리 팀은 무엇을 골라야 하나"를 4가지 도메인(IoT·관찰성·금융·OLAP)별로 답한다.

1장 · 2026년 시계열 DB 지도 — 메트릭·로그·트레이스·IoT 4축

먼저 큰 그림. 2026년의 시계열 DB는 크게 세 가족으로 분류된다.

가족특징대표주자
Postgres 가족표준 SQL, 트랜잭션, JOIN 강함TimescaleDB
전용 TSDB 가족시계열 최적화 압축·인덱스, 메트릭 특화InfluxDB 3, VictoriaMetrics, Prometheus, M3DB, GreptimeDB
컬럼 스토어 가족OLAP에서 출발, 시계열도 잘 됨ClickHouse, QuestDB, Apache Druid, Apache Pinot

그리고 워크로드별로 보면.

워크로드권장 후보이유
Kubernetes 메트릭Prometheus + Mimir, VictoriaMetrics표준 호환, 카디널리티 관리 도구
APM 메트릭 + 트레이스OTel + ClickHouse 또는 GreptimeDBOTLP 직접 수신, 컬럼 압축
IoT 센서 (수십만 디바이스)InfluxDB 3, TDengine, TimescaleDB압축률, 다운샘플링, edge 통합
금융 틱 데이터QuestDB, ClickHouse, TimescaleDBns 단위 정확도, 빠른 시계열 JOIN
일반 분석 + 시계열ClickHouse, TimescaleDBSQL 친숙도, 일반 데이터와 결합
로그 (메트릭과 같이)ClickHouse, GreptimeDB풀텍스트 + 시간 필터

핵심 통찰 한 가지: 시계열 DB를 하나로 통일하려는 시도는 거의 다 실패한다. k8s 관찰성과 IoT를 같은 DB에 우겨넣는 시도는 카디널리티 모델이 달라서 한쪽이 깨진다. 우리 팀의 워크로드를 먼저 정의하고, 맞는 도구를 골라야 한다.

2장 · TimescaleDB — Postgres 위의 시계열

TimescaleDB는 시계열 DB라기보다 시계열 친화 Postgres 확장이다. 2017년 등장한 이래 "SQL을 사랑하지만 시계열 압축과 파티셔닝은 자동화하고 싶다"는 팀의 압도적 1위 선택.

핵심 개념

강점

약점

언제 고르나

-- TimescaleDB hypertable 생성
CREATE TABLE metrics (
  time TIMESTAMPTZ NOT NULL,
  device_id TEXT NOT NULL,
  temperature DOUBLE PRECISION,
  humidity DOUBLE PRECISION
);

SELECT create_hypertable('metrics', 'time');

-- 시간 청크 자동 압축 정책
ALTER TABLE metrics SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'device_id'
);
SELECT add_compression_policy('metrics', INTERVAL '7 days');

-- 연속 집계
CREATE MATERIALIZED VIEW metrics_hourly
WITH (timescaledb.continuous) AS
SELECT
  time_bucket('1 hour', time) AS bucket,
  device_id,
  AVG(temperature) AS avg_temp,
  MAX(temperature) AS max_temp
FROM metrics
GROUP BY bucket, device_id;

3장 · InfluxDB 3 (DataFusion + Arrow) — 완전히 새로워진 InfluxDB

InfluxDB 1.x → 2.x → 3.x로 오면서 내부가 두 번 갈렸다. 2.x의 Flux 언어는 거의 폐기 수순이고, 3.x는 Apache DataFusion 쿼리 엔진 + Apache Arrow 메모리 포맷 + Apache Parquet 스토리지 위에 다시 지어졌다. 사실상 "InfluxDB라는 이름의 Arrow 시계열 데이터베이스"다.

핵심 변화

강점

약점

언제 고르나

-- InfluxDB 3 SQL 예시 (DataFusion)
SELECT
  date_bin('1 hour', time) AS hour,
  device_id,
  AVG(temperature) AS avg_temp
FROM metrics
WHERE time > now() - INTERVAL '7 days'
GROUP BY 1, 2
ORDER BY 1 DESC;

4장 · QuestDB — SQL과 빠른 ingest의 만남

QuestDB는 자바로 작성된, 시계열 특화 컬럼 스토어다. 핵심 어필 포인트는 "Postgres 와이어 프로토콜 + InfluxDB Line Protocol을 동시에 받는다". SQL을 쓰면서 InfluxDB 호환 클라이언트로 ingest 할 수 있다는 뜻.

핵심 개념

강점

약점

언제 고르나

-- QuestDB ASOF JOIN — 시계열 특화
SELECT
  trades.timestamp,
  trades.symbol,
  trades.price,
  quotes.bid,
  quotes.ask
FROM trades
ASOF JOIN quotes
WHERE trades.symbol = quotes.symbol
  AND trades.timestamp > '2026-01-01';

5장 · ClickHouse — 컬럼 스토어의 압도적 성능

ClickHouse는 엄밀히 말해 시계열 DB가 아니라 OLAP 컬럼 스토어다. 그런데 시간 컬럼으로 정렬·파티션하면 시계열 DB로 쓸 수 있고, 거기서 다른 시계열 DB들을 압도하는 분석 성능을 낸다. 2024-2026 사이 옵저버빌리티 영역에서 가장 많이 채택된 백엔드 중 하나.

핵심 개념

강점

약점

언제 고르나

-- ClickHouse: 시계열 + Gorilla 압축
CREATE TABLE metrics (
  time DateTime64(3, 'UTC') CODEC(DoubleDelta, ZSTD),
  device_id LowCardinality(String),
  metric LowCardinality(String),
  value Float64 CODEC(Gorilla, LZ4)
) ENGINE = MergeTree
PARTITION BY toYYYYMM(time)
ORDER BY (device_id, metric, time);

-- 사전 집계 머티리얼라이즈드 뷰
CREATE MATERIALIZED VIEW metrics_hourly
ENGINE = AggregatingMergeTree
PARTITION BY toYYYYMM(hour) ORDER BY (device_id, metric, hour) AS
SELECT
  toStartOfHour(time) AS hour,
  device_id,
  metric,
  avgState(value) AS avg_v,
  maxState(value) AS max_v
FROM metrics GROUP BY hour, device_id, metric;

6장 · VictoriaMetrics — Prometheus 호환 + 가벼움

VictoriaMetrics(이하 VM)는 한 문장으로 "Prometheus와 호환되는데 더 빠르고 가볍고 디스크 효율이 좋다". Prometheus의 PromQL을 거의 그대로 받고, 그 위에 MetricsQL이라는 확장을 얹는다. 2020년부터 꾸준히 성장해 2026년에는 큰 규모 메트릭 백엔드의 표준 옵션 중 하나로 자리잡았다.

핵심 개념

강점

약점

언제 고르나

# vmagent로 Prometheus 스크레이프 대체
vmagent \
  -promscrape.config=/etc/scrape_config.yml \
  -remoteWrite.url=http://vmstorage:8480/insert/0/prometheus/

# PromQL 그대로
sum(rate(http_requests_total[5m])) by (service)

# MetricsQL 확장
rollup_rate(http_requests_total[5m]:1m)

7장 · Prometheus + Mimir — Kubernetes 메트릭의 표준

Prometheus는 2026년에도 Kubernetes 메트릭의 사실상 표준이다. CNCF Graduated 프로젝트로 어디서나 돌아간다. 한계는 명확하다 — 장기 보관과 수평 확장. 이를 해결하기 위한 옵션 중 가장 보편적인 것이 Grafana Mimir (Cortex의 후계).

Prometheus의 위치

Mimir가 해결하는 것

경쟁자

옵션특징
Grafana MimirCortex 후계, Grafana Labs 주도
Thanos사이드카 모델, 같은 문제 다른 답
VictoriaMetrics cluster더 단순, MetricsQL 확장
CortexMimir로 사실상 흡수됨

강점·약점

강점: Kubernetes·CNCF 생태계와 완벽 통합, exporter 풀, 표준 PromQL. 약점: 메트릭 외(로그/트레이스)는 별도 스택, 카디널리티 폭발 시 운영이 무거움.

언제 고르나

8장 · GreptimeDB — Rust 기반 신예

GreptimeDB는 2022년 등장한 Rust 기반 시계열 DB로, 2024-2026 사이 빠르게 성장했다. 목표가 야심차다 — 메트릭·로그·트레이스를 한 DB에서, 클라우드 네이티브로.

특징

강점

약점

언제 고르나

9장 · M3DB / TDengine / OpenTSDB — 그 외 후보들

M3DB

TDengine

OpenTSDB

Apache Druid / Pinot

10장 · 압축 전략 — Gorilla, ZSTD, Snappy

시계열 DB에서 디스크 사용량은 곧 비용이다. 그래서 2026년의 모든 메이저 TSDB는 여러 코덱을 조합한다.

시계열 특화 코덱

범용 코덱 (위 단계 다음에)

조합 패턴

대부분의 시계열 DB는 "시계열 특화 코덱 → 범용 코덱"을 파이프라인으로 적용한다. 예를 들어 ClickHouse:

이 조합으로 보통 원본 대비 5~20배 압축. 디스크 비용이 1/10 이하로 떨어진다.

11장 · 카디널리티 폭발 — 시계열 DB의 1번 적

"카디널리티(cardinality)"는 시계열 DB에서 가장 자주 폭발하는 항목이다. 정의는 단순하다 — 고유한 시계열의 개수.

무엇이 카디널리티를 폭발시키나

각 시계열은 보통 다음과 같이 정의된다.

metric_name{label1=value1, label2=value2, ...}

라벨의 값 조합 수가 곧 series 수다. 위험한 라벨 예:

폭발하면 무슨 일이 일어나나

해결 방법

  1. 라벨 위생 — 카디널리티 폭발 라벨을 식별하고 메트릭에서 빼거나, 별도로 트레이스/로그로 이동.
  2. 카디널리티 가시성 — VictoriaMetrics의 vmui cardinality explorer, Prometheus의 cardinalities 쿼리, Grafana Mimir의 분석.
  3. 카디널리티 limit — 한 series당 라벨 값 한도를 ingest 단에서 강제.
  4. Drop / Rewrite 규칙 — 스크레이프 단계에서 위험한 라벨 제거.
  5. 샘플링·집계 — 모든 series를 보관하지 않고, 핵심 집계만.

"트레이스로 보내라" 원칙

높은 카디널리티 디멘션(사용자·요청 ID·트레이스 ID)은 메트릭이 아니라 트레이스로 보내는 것이 2026년의 표준 답이다. 메트릭은 집계, 트레이스는 디테일.

12장 · 표준 — Prometheus 노출 형식·OpenMetrics·OTel

서로 다른 시계열 DB를 보더라도, 데이터를 그쪽에 흘려보내는 표준은 점점 통합되고 있다.

Prometheus exposition format

# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 1234 1715814000000
http_requests_total{method="POST",status="201"} 56 1715814000000

OpenMetrics

OpenTelemetry (OTel)

InfluxDB Line Protocol

measurement,tag1=value1 field1=1.0 1715814000000000000

권장 접근

새 프로젝트라면 OTel(OTLP)을 1급 시그널로, 그리고 백엔드에 따라 Prometheus 형식 또는 OTLP 직접 수신. 메이저 TSDB는 모두 둘 다 지원한다.

13장 · IoT vs APM vs 금융 — 누가 무엇을 골라야 하나

이제 종합. 도메인별로 2026년 5월 기준의 권장.

Kubernetes/관찰성 (메트릭 중심)

멀티 시그널 옵저버빌리티 (메트릭 + 로그 + 트레이스 통합)

IoT/센서 (수십~수백만 디바이스)

금융 시장 데이터 (틱·호가)

일반 OLAP + 시계열

안티패턴 7가지

  1. "시계열 DB 하나로 다" — 워크로드를 안 나누면 카디널리티 모델이 깨진다.
  2. 메트릭에 사용자 ID·요청 ID 박기 — 카디널리티 폭발.
  3. 압축 코덱 기본값 그대로 — 컬럼 특성에 맞게 골라야 5배 차이.
  4. 보관 정책 없이 무한 누적 — 디스크 비용이 1년 만에 폭주.
  5. continuous aggregate 안 쓰기 — 매번 raw에서 집계.
  6. Prometheus만으로 1년+ 보관 — Mimir/VictoriaMetrics/Thanos 둘 중 하나.
  7. 메트릭과 트레이스 책임 혼동 — 디테일은 트레이스로, 집계는 메트릭으로.

다음 글 예고

"시계열은 한 가지 워크로드가 아니다. 메트릭·로그·트레이스·IoT는 같은 모양으로 보여도 다른 문제다. 다른 도구로 푸는 게 정답이다."

— 시계열 데이터베이스 2026, 끝.

참고 / References

원문 보기: https://www.youngju.dev/blog/culture/2026-05-15-time-series-databases-2026-timescaledb-influxdb-3-questdb-clickhouse-victoriametrics-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다