時系列データベース 2026 — TimescaleDB / InfluxDB 3 / QuestDB / ClickHouse / VictoriaMetrics 徹底比較

プロローグ — 「時系列DBひとつで全部こなす時代は終わった」

2017年頃まで「時系列DB?」と聞けば、InfluxDB 1.xの名前ひとつしか出てこなかった。2020年にはPrometheusがメトリクスの標準になり、TimescaleDBがSQLを武器にPostgres上で登場した。2023年にはClickHouseがOLAP側から時系列領域を侵食しはじめ、QuestDBがJavaで高速ingestを引っ提げて現れた。

2026年現在、私たちが「時系列データ」と呼んでいるものの中には、少なくとも4つの異なるワークロードが含まれている。

1. メトリクス (metrics) — CPU・メモリ・QPSのような時間あたりの数値。カーディナリティ爆発が主な敵。
2. ログ (logs) — タイムスタンプ + メッセージというテキスト1行。全文検索 + 時間フィルタ。
3. トレース (traces) — 分散システムのspan。span-id・trace-idでつながったグラフ構造。
4. IoT / センサー (telemetry) — デバイス・車両・工場のセンサー時系列。圧縮率と取り込みスループットが重要。

この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は大きく3つのファミリーに分類される。

ワークロード別に見ると。

ひとつ重要な洞察 — 時系列DBをひとつに統一しようとする試みはほとんど失敗する。k8s観測とIoTを同じDBに押し込むとカーディナリティモデルが根本的に異なるため、どちらかが壊れる。チームのワークロードをまず定義し、適切なツールを選ぶ。

2. TimescaleDB — Postgresの上の時系列

TimescaleDBは時系列DBというより時系列フレンドリーなPostgres拡張だ。2017年に登場して以来、「SQLは大好きだが時系列の圧縮とパーティショニングは自動化したい」というチームの圧倒的1番手。

コアコンセプト

• Hypertable — 時間カラムで自動パーティション分割されたテーブル。ユーザーには普通のテーブルに見える。
• Chunk — Hypertableの時間チャンク（例：7日単位）。古いチャンクは圧縮・移動・削除可能。
• Continuous Aggregate — マテリアライズドビュー + 自動リフレッシュ。事前集計の結果を高速に読む。
• Compression — 行ベース → カラムベースに変換してから圧縮（通常90%以上節約）。

強み

• 標準PostgreSQL — JOIN、ウィンドウ、CTE、外部キー、JSON、地理情報まで全部使える。
• フルスタック — 時系列だけでなくリレーショナルデータも1つのDBで扱える。
• 運用者がPostgresに慣れている — バックアップ・レプリケーション・監視ツールがそのまま。
• Timescale Cloud（マネージド）も成熟。

弱み

• メトリクスのカーディナリティ面ではPrometheus・VictoriaMetricsより重い。
• 100万series以上になるとインデックスコストが急増。
• 大規模OLAPクエリではClickHouseほど速くない。

いつ選ぶか

• すでにPostgresを使っており、時系列が副次的なワークロードのチーム。
• SQL JOINが頻繁に必要な場合（例：デバイスメタデータとセンサーデータの結合）。
• 金融分析のように精度とトランザクションが重要な場合。

-- 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度書き直された。2.xのFlux言語はほぼ廃止扱いで、3.xはApache DataFusionクエリエンジン + Apache Arrowメモリフォーマット + Apache Parquetストレージの上に作り直された。実質「InfluxDBという名のArrow時系列データベース」。

コアの変化

• 言語 — InfluxQLとSQL両対応。Fluxは事実上非推奨。
• エンジン — Rustで書かれたIOxエンジン。DataFusionがクエリプランナ。
• ストレージ — Parquetファイル + オブジェクトストレージ（S3、GCS）ベース。
• エディション — Core（OSS、シングルノード）、Enterprise（クラスタ + HA）、Cloud（マネージド、サーバーレス）。

強み

• 標準SQL対応 — FluxやInfluxQLの学習負担が消える。
• Arrow Flight SQLによるクライアント通信 — 高速で標準化。
• オブジェクトストレージへの直接書き込み — 実質無制限保管、安価。
• IoTワークロード向けの圧縮率・取り込みスループットが優秀。

弱み

• 2.x → 3.xの移行パスがきれいでない。2.xを運用中なら痛みを伴う。
• クラスタ（Enterprise）は有料。大規模なOSSオプションが弱い。
• エコシステムがTelegraf・Chronograf時代に比べて分散している。

いつ選ぶか

• IoT / センサーデータ — 数十万デバイス、圧縮が肝の場合。
• 既にInfluxDB 1.x / 2.xを使っているなら移行先として。
• オブジェクトストレージに時系列をフラットに積みたい場合。

-- 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はJavaで書かれた時系列特化のカラムストアだ。コアの売り文句は「Postgresワイヤープロトコル + InfluxDB Line Protocolを同時に受ける」。SQLを使いつつInfluxDB互換クライアントでingestできるという意味。

コアコンセプト

• SYMBOL型 — 繰り返される文字列をdictionary encodingで保存。カーディナリティ管理に効果的。
• PARTITION BY — DAY/MONTH/HOUR単位パーティション。古いパーティションは保持ポリシーで自動削除。
• DEDUP — 同じtimestamp + キーの重複を自動除去。
• ILP (InfluxDB Line Protocol) — TCP/HTTPで行単位ingest。

強み

• 取り込みスループットが非常に高い — シングルノードで数百万行/秒可能。
• SQLが標準に近い — PGワイヤーで一般クライアントがそのまま接続。
• 高速な時系列JOIN — ASOF JOIN（最も近い時間）への深いサポート。
• 金融ティックデータ界隈での評判。

弱み

• クラスタ（分散）はEnterprise有料。OSSはシングルノード。
• エコシステムが小さい — 運用ツール・サンプル・SI人材が他候補比で少ない。
• 一般データ（トランザクション）には向かない。

いつ選ぶか

• 金融市場データ（ティック） — 高速ASOF JOINと精度が必須。
• シングルノードで非常に高い取り込みスループットが必要な場合。
• SQLを使いつつInfluxDBクライアント互換が欲しい場合。

-- 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年で観測領域で最も採用されたバックエンドの1つ。

コアコンセプト

• MergeTreeエンジンファミリー — ORDER BYでソート、PARTITION BYで分割。ReplicatedMergeTreeで複製。
• カラム圧縮 — LZ4（デフォルト）、ZSTD、Delta、DoubleDelta、Gorillaなどのコーデックを選択可能。
• Materialized View — トリガベース事前集計。continuous aggregateに類似。
• Projection — 同じデータを別ソートでもう1度保存 → 別のクエリパターンにも高速。

強み

• 分析クエリ速度が圧倒的 — 同級のOLAP DBと比べても上位。
• 多様なコーデック — Gorilla（浮動小数点）、DoubleDelta（時間）など時系列特化。
• ほぼ全ての入出力 — JDBC、ODBC、HTTP、Kafka統合、Parquet外部テーブル。
• 巨大データ（数十〜数百TB）でも動く。

弱み

• 単件UPDATE/DELETEに弱い（バッチマージモデル）。トランザクションワークロードには不向き。
• 運用が複雑 — マージ・複製・ZooKeeper（またはClickHouse Keeper）の学習が必要。
• メトリクスのカーディナリティ面でInfluxDB・VictoriaMetricsほど自動化されていない。

いつ選ぶか

• OpenTelemetryバックエンド — OTelトレース/ログ/メトリクス統合保存。
• 大規模ログ分析。
• BI + 時系列結合（アナリストがSQLで自由にクエリ）。
• ユーザー行動イベント + 時系列統合DW。

-- 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）を1文で言うと「Prometheusと互換性があるが、より速く、軽く、ディスク効率が良い」。PromQLをほぼそのまま受け、その上にMetricsQLという拡張を載せる。2020年から着実に成長し、2026年には大規模メトリクスバックエンドの標準オプションの1つになった。

コアコンセプト

• vmstorage / vmselect / vminsert — クラスタで責務分離されたコンポーネント。
• vmagent — Prometheusのスクレイプ代替。remote_writeも対応。
• vmalert — Prometheusアラートルール互換。
• MetricsQL — PromQL上位互換 + 拡張（rollup関数、histogram_quantile改善など）。

強み

• Prometheus互換 — ダッシュボード（Grafana）とアラートルールがそのまま。
• ディスク使用量が小さい — Prometheus比で7倍以上節約の事例が普通。
• 運用がシンプル — シングルバイナリOSS、クラスタオプション両方明快。
• カーディナリティ管理ツールがよくできている（cardinality explorer）。

弱み

• 「Prometheus + 軽量」以外の差別化は薄い。その価値が明確でなければわざわざ?
• ログ・トレースは別（VictoriaLogs、VictoriaTraces）。統合ソリューションではない。
• 分散クラスタ運用はそれなりに手間がかかる。

いつ選ぶか

• 既にPrometheusを使っており、保持期間 / カーディナリティの限界にぶつかった時。
• シングルノードで大規模メトリクス負荷を受ける場合。
• カーディナリティ可視性が必要な場合。

# 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の位置

• pullベースメトリクス — /metricsエンドポイントを定期スクレイプ。
• PromQL — メトリクスクエリの事実上の標準言語。
• ローカルディスクのTSDB。通常15日程度保持。

Mimirが解決すること

• 長期保管 — オブジェクトストレージ（S3/GCS）にフラットに蓄積。1年+保管が普通に。
• 水平スケール — distributor / ingester / store-gateway / querierなどコンポーネント分離。
• マルチテナント — 1クラスタで複数チームのメトリクスを隔離。
• グローバルビュー — 複数のPrometheusインスタンスを1つに合わせてクエリ。

競合

強み・弱み

強み：Kubernetes・CNCFエコシステムと完璧に統合、exporterプール、標準PromQL。 弱み：メトリクス以外（ログ・トレース）は別スタック、カーディナリティ爆発時の運用が重い。

いつ選ぶか

• Kubernetesクラスタのインフラ / アプリケーションメトリクスがメインの時。
• 既にPromQLとGrafanaで標準化されたチーム。
• マルチテナント観測プラットフォームを構築する時（Mimir選択）。

8. GreptimeDB — Rust基盤の新鋭

GreptimeDBは2022年に登場したRust基盤の時系列DBで、2024-2026年に急成長した。目標は野心的 — メトリクス・ログ・トレースを1つのDBで、クラウドネイティブに。

特徴

• Rust製 — メモリ安全性と性能。
• SQL + PromQL + InfluxQL同時対応 — 移行フレンドリー。
• ローカル + オブジェクトストレージ分離 — コンピュートとストレージ分離、S3に直接書き込み。
• OpenTelemetryネイティブ — OTLP受信を1級として。

強み

• 1つのDBでメトリクス・ログ・トレース — 統合観測ソリューションとして魅力。
• オブジェクトストレージ分離 — 安価な長期保管。
• 活発なOSSコミュニティ、クラウドオプションもあり。

弱み

• まだ成熟度の面でPrometheus・ClickHouseほど検証されていない。
• 運用経験のプールが小さい。
• 大規模production事例が相対的に少ない。

いつ選ぶか

• 新しい観測スタックをゼロから組む時。
• OTel標準に沿ったメトリクス / ログ / トレース統合が目標の時。
• Rust基盤の軽量さとシンプルさを好む時。

9. M3DB / TDengine / OpenTSDB — その他候補

M3DB

• Uberが作ってオープンソース化した分散TSDB。
• メトリクス・インデックス・集計のコンポーネント分離。
• Uber内部規模（数億series）で検証済み。
• 弱み：外部採用は狭く、運用が複雑。

TDengine

• 中国Taos DataのIoT特化TSDB。
• デバイス1つあたり1テーブルモデル — IoTカーディナリティに効率的。
• 独自SQLとクラスタオプション。
• 弱み：英語圏コミュニティが小さく、一部機能はEnterprise。

OpenTSDB

• HBase上に時系列インデックスを載せた第1世代TSDB。
• 安定性は良いがエコシステムが停滞。
• 新規プロジェクトでは選ばれない。

Apache Druid / Pinot

• 厳密にはTSDBではないが、時間次元が大きいOLAPで頻出。
• リアルタイムダッシュボード・イベント分析に強い。
• 時系列メトリクスバックエンドとしては重い。

10. 圧縮戦略 — Gorilla、ZSTD、Snappy

時系列DBではディスク使用量がそのままコストだ。だから2026年のあらゆるメジャーTSDBは複数のコーデックを組み合わせる。

時系列特化コーデック

• Gorilla (Facebook) — 浮動小数点時系列特化。XOR + 可変長符号化で平均1.37バイト/ポイント。
• Delta encoding — 整数シーケンスで隣接値の差分のみ保存。timestampに特に好適。
• DoubleDelta — DeltaのDelta。時間カラムのようにほぼ一定間隔で非常に有効。
• RLE (Run-Length Encoding) — 同じ値が繰り返されるシーケンスを圧縮。
• Dictionary encoding — 繰り返し文字列をIDに（QuestDB SYMBOL、ClickHouse LowCardinality、Parquet dictionary）。

汎用コーデック（上の段の後に）

• LZ4 — 最速、圧縮率は普通。ホットデータに適合。
• Snappy — Google製。LZ4と類似の位置。
• ZSTD — Facebook製。圧縮率と速度のバランスが優秀。コールドデータに頻用。
• gzip — 古い標準。圧縮率は良いが速度は落ちる。

組み合わせパターン

ほとんどの時系列DBは「時系列特化コーデック → 汎用コーデック」をパイプライン適用する。例えばClickHouse：

• 時間カラム：DoubleDelta + ZSTD
• 測定値（float）：Gorilla + LZ4
• カテゴリ文字列：LowCardinality + ZSTD

この組み合わせで通常原本比5〜20倍圧縮。ディスクコストは1/10以下に下がる。

11. カーディナリティ爆発 — 時系列DBの1番の敵

「カーディナリティ」は時系列DBで最も頻繁に爆発する項目だ。定義はシンプル — ユニークな時系列の個数。

何がカーディナリティを爆発させるか

各時系列は通常以下のように定義される。

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

ラベルの値の組み合わせ数がそのままseries数だ。危険なラベルの例：

• ユーザーID — ユーザー100万人ならseries100万倍。
• リクエストID・セッションID・trace ID — ほぼ無限。
• IPアドレス — 動的IPなら爆発。
• パラメータ付きURLパス — /user/12345/order/67890。
• 生のエラーメッセージ — 可変部分が入ると爆発。

爆発すると何が起きるか

• インデックスがメモリに収まらない → クエリ詰まり。
• ディスク使用量急増。
• ingestが遅くなりメトリクス欠損。
• Grafanaダッシュボードがタイムアウト。

解決方法

1. ラベル衛生 — 爆発ラベルを特定してメトリクスから外す、もしくはトレース / ログに移す。
2. カーディナリティ可視性 — VictoriaMetricsのvmui cardinality explorer、Prometheusのカーディナリティクエリ、Grafana Mimirの分析。
3. カーディナリティ制限 — 1 seriesあたりのラベル値上限をingest側で強制。
4. Drop / Rewriteルール — スクレイプ段階で危険ラベルを除去。
5. サンプリング・集計 — 全seriesを保管せず、コア集計のみ。

「トレースに送れ」原則

高カーディナリティのディメンション（ユーザー・リクエストID・トレースID）はメトリクスではなくトレースに送るのが、2026年の標準答え。メトリクスは集計、トレースは詳細。

12. 標準 — Prometheus exposition、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

• 最も普遍的。すべてのTSDBが受けるか変換する。
• counter、gauge、histogram、summaryの4種。

OpenMetrics

• Prometheus形式のIETF標準化版。
• ExemplarLinkでトレースとリンク可能。
• 基本的にPrometheus形式と互換。

OpenTelemetry (OTel)

• メトリクス・ログ・トレース統合標準。
• OTLPプロトコルでcollectorまたは直接バックエンドへ送信。
• 2026年事実上のマルチシグナル標準。

InfluxDB Line Protocol

measurement,tag1=value1 field1=1.0 1715814000000000000

• InfluxDB・QuestDB・一部のIoTバックエンドが受ける。
• IoTゲートウェイで軽量オプションとして頻繁に。

推奨アプローチ

新規プロジェクトならOTel（OTLP）を1級シグナルに、バックエンドに応じてPrometheus形式またはOTLPを直接受信。メジャーTSDBはすべて両方サポート。

13. IoT vs APM vs 金融 — 誰が何を選ぶべきか

総合へ。ドメイン別の2026年5月時点の推奨。

Kubernetes / 観測（メトリクス中心）

• 第1選択：Prometheus + Grafana Mimir（またはVictoriaMetricsクラスタ）。
• 理由：PromQL標準、豊富なエコシステム、成熟したカーディナリティ管理ツール。
• トレース / ログも必要なら：+ Tempo + Loki、またはClickHouseで統合。

マルチシグナル観測（メトリクス + ログ + トレース統合）

• 第1選択：ClickHouse（OTelバックエンドとして）またはGreptimeDB。
• 理由：1つのDBでSQLで3つのシグナル、カラム圧縮で費用節約。
• 欠点：運用負担はPrometheusより重い。

IoT / センサー（数十〜数百万デバイス）

• 第1選択：InfluxDB 3またはTDengineまたはTimescaleDB。
• 理由：圧縮率、取り込みスループット、ダウンサンプリング、エッジ統合。
• 選択基準：圧倒的な取り込みが必要ならTDengine / QuestDB、SQLと一般データの結合ならTimescaleDB、オブジェクトストレージ統合ならInfluxDB 3。

金融市場データ（ティック・気配値）

• 第1選択：QuestDBまたはClickHouseまたはkdb+。
• 理由：ナノ秒timestamp、ASOF JOIN、高速時系列分析。
• kdb+の位置：一部ヘッジファンドの最上位選択は今も。コスト・人材プールが参入障壁。

一般OLAP + 時系列

• 第1選択：ClickHouseまたはTimescaleDB。
• 理由：SQLでBI・時系列結合。
• 選択基準：トランザクション / リレーショナル結合が大きいならTimescaleDB、大規模分析クエリがメインならClickHouse。

アンチパターン7つ

1. 「時系列DB1つで全部」 — ワークロードを分けないとカーディナリティモデルが壊れる。
2. メトリクスにユーザーID・リクエストIDを入れる — カーディナリティ爆発。
3. 圧縮コーデックをデフォルトのまま — カラム特性に合わせれば5倍差。
4. 保持ポリシーなしで無限蓄積 — ディスクコストが1年で暴走。
5. continuous aggregateを使わない — 毎回rawから集計。
6. Prometheus単独で1年+保管 — Mimir / VictoriaMetrics / Thanosのどれかを。
7. メトリクスとトレースの責務混同 — 詳細はトレース、集計はメトリクス。

次の記事予告

• 次候補：OpenTelemetry深掘り — Collector・Processor・Exporter実戦、Grafanaダッシュボード設計ガイド、カーディナリティ爆発の事例分析と運用パターン。

「時系列は1つのワークロードではない。メトリクス・ログ・トレース・IoTは同じ形に見えても違う問題だ。違うツールで解くのが正解だ。」

— 時系列データベース 2026、了。

参考 / References

• TimescaleDB Documentation
• TimescaleDB GitHub — timescale/timescaledb
• InfluxDB 3 Documentation
• InfluxDB 3 Core/Enterprise — InfluxData
• InfluxDB IOx — GitHub
• Apache DataFusion
• Apache Arrow
• QuestDB Documentation
• QuestDB GitHub — questdb/questdb
• ClickHouse Documentation
• ClickHouse GitHub — ClickHouse/ClickHouse
• ClickHouse Codecs
• VictoriaMetrics Documentation
• VictoriaMetrics GitHub — VictoriaMetrics/VictoriaMetrics
• Prometheus Documentation
• Grafana Mimir
• Grafana Mimir GitHub — grafana/mimir
• Thanos — long-term Prometheus
• GreptimeDB
• GreptimeDB GitHub — GreptimeTeam/greptimedb
• M3DB GitHub — m3db/m3
• TDengine GitHub — taosdata/TDengine
• OpenTSDB
• Apache Druid
• Apache Pinot
• OpenMetrics specification
• OpenTelemetry specification
• Gorilla — Facebook in-memory TSDB paper
• Facebook ZSTD
• Snappy compressor
• Prometheus high-cardinality guidance