# VictoriaMetrics vs Prometheus: どちらのメトリクスストア?

> VictoriaMetrics vs Prometheus: 高効率な時系列データベースと、標準的な監視システム。パフォーマンス、保持、CI への適合を比較します。

Source: https://latchkey.dev/ja/learn/tool-comparisons/victoriametrics-vs-prometheus  
Updated: 2026-06-26

VictoriaMetrics は Prometheus 互換の、高速でストレージ効率の高い時系列データベースです。Prometheus は標準的な pull ベースの監視システムです。

Prometheus は PromQL、スクレイピング、巨大なエコシステムを備えた事実上の監視標準ですが、ストレージは single-node であり、非常に長期の保持向けには作られていません。VictoriaMetrics は PromQL (MetricsQL) を話し、Prometheus のデータを取り込み、より高い圧縮、より良い長期保持、クラスタリングを提供します。Prometheus はエコシステムの遍在性で勝り、VictoriaMetrics は効率、保持、規模で勝ります。

## Comparison

|  | VictoriaMetrics | Prometheus |
| --- | --- | --- |
| 役割 | TSDB / 長期ストア | 監視 + 短期 |
| クエリ | MetricsQL (PromQL+) | PromQL |
| 圧縮 | 非常に高い | 良好 |
| スケーリング | クラスタモード | single-node ストレージ |
| 最適な用途 | 効率、保持 | 標準的な監視 |

## ユースケースと効率

Prometheus は、最も幅広いエコシステムを備えた標準的なスクレイピング、アラート、短期から中期の保持に適しています。VictoriaMetrics は、長期保持、低いストレージコスト、高いインジェストを必要とするチームに適しており、しばしば Prometheus のスクレイピングの背後にドロップインの長期バックエンドとして使われます。

## 運用と CI への適合

VictoriaMetrics は運用が軽くリソース効率が高いことで有名です。Prometheus はシンプルですが長期保持には add-on が必要です。どちらもコンテナ化され CI でテストされ、より高速なマネージドランナーが build とクエリ互換性テストを高速化します。

## Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

```Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"
```

> Measure the cold path. Warm local benchmarks favour whichever tool you already have cached, which is exactly the condition a CI runner never has.

## What actually changes when you switch

- Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
- Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
- CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
- Everyone on the team and every runner must move together. Pin the version so they cannot drift.

## 結論

標準的な監視とアラートのエコシステムが欲しいなら Prometheus。PromQL 互換で高い効率、長期保持、クラスタリングが欲しいなら VictoriaMetrics。多くの場合両方を運用し、Prometheus でスクレイプして VictoriaMetrics に保存します。

## FAQ

### VictoriaMetrics vs Prometheus: Which Metrics Store?

Prometheus is the de facto monitoring standard with PromQL, scraping, and a huge ecosystem, but it is single-node for storage and not built for very long retention. VictoriaMetrics speaks PromQL (MetricsQL), ingests Prometheus data, and offers higher compression, better long-term retention, and clustering.

### Use case and efficiency?

Prometheus suits standard scraping, alerting, and short-to-medium retention with the broadest ecosystem. VictoriaMetrics suits teams needing long retention, lower storage cost, and higher ingest, often as a drop-in long-term backend behind Prometheus scraping.

### Ops and CI fit?

VictoriaMetrics is famously light to operate and resource-efficient; Prometheus is simple but needs add-ons for long retention. Both are containerized and tested in CI, where faster managed runners speed builds and query-compatibility tests.

### Which should I choose?

Want the standard monitoring and alerting ecosystem: Prometheus. Want higher efficiency, long retention, and clustering with PromQL compatibility: VictoriaMetrics. Many run both, scraping with Prometheus and storing in VictoriaMetrics.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt