OpenObserve vs Prometheus & Mimir: Metrics Benchmark

A vendor-authored, reproducible benchmark compared single-node Prometheus, Grafana Mimir, and OpenObserve using Parquet and Vortex formats on matched EC2 hardware after ingesting approximately 2.2 billion samples across 1.09 million active histogram series. With caches disabled, limits raised consistently, ingestion stopped, and identical PromQL queries run against frozen time windows, OpenObserve delivered substantially lower latency for irate and unfiltered high-cardinality histogram queries, while both Prometheus and Mimir required raised default query limits to process the million-series workload. OpenObserve used less ingestion memory and remained stable under a 14 GB memory limit, whereas Prometheus was OOM-killed during wider unfiltered histogram queries, but OpenObserve consumed more CPU during ingestion and roughly 2.5 times Prometheus’s settled local disk space. File format significantly affected filtered histogram performance: Vortex was about three times faster than Parquet and outperformed both TSDB-based systems for the six-hour filtered tests, while the formats performed similarly for broad scans. The results position Prometheus as suitable for modest-cardinality, ecosystem-focused deployments, Mimir as a scalable Prometheus-compatible option with favorable CPU and disk use, and OpenObserve—particularly with Vortex—as a potential alternative for workloads dominated by high cardinality, memory pressure, and dashboard-style filtered queries.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.