---
title: "How Pitot compares"
summary: "The comparison table from the project README."
description: "Compare the deployment shape and scope of Pitot with other telemetry systems."
status: preview
read_when:
  - "You are deciding whether one Pitot instance fits your workload."
---
| If you use | Where Pitot differs |
| --- | --- |
| **Grafana with Loki, Tempo, and Mimir** | That stack keeps a service and a query language per signal, plus object storage underneath. Pitot keeps one process, one data directory, and one typed contract across all three signals, at the cost of the horizontal scale those components are built for. |
| **SigNoz** | Both are OTLP-native and self-hosted. SigNoz composes a collector, ClickHouse, and query services; Pitot compiles ingest, authoritative Parquet storage, indexed trace reads, DuckDB analytics, alerting, and the browser client into one binary. |
| **Jaeger** | Jaeger covers traces and expects a storage backend you run separately. Pitot ingests traces, logs, and metrics into the same store, with nothing else to deploy. |
| **Prometheus with Grafana** | Prometheus pulls metrics and is excellent at them. Pitot accepts pushed OTLP for all three signals and is built around investigating a specific incident rather than maintaining long-range metric series. |
| **Datadog**, **Honeycomb**, **Grafana Cloud** | Those are managed services: someone else runs the storage, the scaling, and the upgrades, and your telemetry leaves your network to get there. Pitot is a binary you run, on data that stays on your disk. |
| **An OpenTelemetry Collector piped into ClickHouse** | The same shape, assembled by hand: collector, database, dashboards, and the glue between them. Pitot is that assembly as one program, with an agent and an MCP server already wired to the same query contract. |

Pitot is a single node. It has no clustering, no replication, and no object tier; a deployment that
outgrows one machine's disk and CPU has outgrown Pitot.