Gigapipe

Open-source observability for logs, metrics, traces, and profiles — honestly reviewed. No marketing fluff, just what you get when you replace Datadog with something you actually own.

TL;DR

• What it is: Open-source (AGPL-3.0) all-in-one observability platform — logs, metrics, traces, and profiling in a single stack, drop-in compatible with Loki, Prometheus, Tempo, and Pyroscope [README][website].
• Who it’s for: Engineering teams and DevOps engineers tired of Datadog or Grafana Cloud sticker shock who want to self-host observability without stitching together five different tools. Not aimed at non-technical users — this is an infrastructure tool [README][5].
• Cost savings: Datadog and Grafana Cloud use usage-based pricing that escalates sharply with data volume. Gigapipe self-hosted is free (AGPL-3.0) on your own hardware; their managed cloud uses flat-rate pricing with no per-query or per-ingestion fees [5][website].
• Key strength: Drop-in API compatibility with the entire Grafana LGTM stack — you can point your existing Loki agents, Prometheus scrapers, and Tempo clients at Gigapipe without changing a line of instrumentation [README][website].
• Key weakness: 1,644 GitHub stars — tiny compared to the observability tools it competes with (SigNoz has 26K, OpenObserve 18K). The community is smaller, documentation depth is uneven, and you’ll find fewer third-party guides when things break [2][3][4].

---

What is Gigapipe

Gigapipe is a polyglot observability platform. “Polyglot” is the word the project uses constantly and it’s an accurate one: instead of implementing a proprietary data model and forcing you to re-instrument everything, Gigapipe acts as a drop-in backend for standards your stack probably already speaks — Loki (logs), Prometheus (metrics), Tempo (traces), Pyroscope (profiling), OpenTelemetry (all of the above), plus Datadog, InfluxDB, and Elastic ingest formats [README][website].

The project started in 2018 as “cLoki,” evolved into “qryn,” and was eventually rebranded Gigapipe. It’s built by Metrico, a small indie team, not a VC-backed company with a large engineering org [about page]. The GitHub repo lives at metrico/gigapipe with 1,644 stars and 89 forks as of this writing [2][3].

Under the hood, Gigapipe uses ClickHouse or DuckDB as the OLAP storage engine, with optional S3 object storage. The team’s pitch is that it runs “like a lightweight transpiler on top of OLAP SQL storage” — rather than reimplementing its own columnar database, it leverages proven OLAP engines and adds the API translation layer on top [about page]. This is a reasonable architectural choice: ClickHouse in particular is excellent at time-series analytics, and it’s what a number of observability tools (including Signoz) also use under the hood.

The tagline “Open-Source != Open Core” is intentional [website]. The entire stack is AGPL-3.0 licensed, which means no paid enterprise tier with gated features — everything is in the open repo. That’s worth taking seriously, because most “open source” observability tools save the good parts for paid plans.

---

Why people choose it over Datadog, Grafana Cloud, and SigNoz

The primary reason people land on Gigapipe is the combination of Grafana ecosystem compatibility and flat-rate pricing — the two things they miss most when escaping managed observability vendors.

The Datadog problem. Gigapipe’s own blog post [5] frames the battle clearly: Datadog charges separately for infrastructure monitoring, log management, APM, and more. Grafana Cloud charges based on ingestion rates, retention, and user management. Both use models that make monthly bills hard to predict and nearly impossible to cap. A startup that onboards Datadog with free credits routinely reports 10x bill increases 6 months later when the credits expire [5]. Gigapipe’s counter-offer is a flat rate based on data volume — you know what you’re paying, it doesn’t spike when your application has an incident and logs suddenly explode [5][website].

The Grafana LGTM stack problem. The “self-hosted Grafana” answer to Datadog usually means running Loki for logs, Mimir for metrics, Tempo for traces, Pyroscope for profiling, and Grafana for visualization — five separate services, each with its own storage, each requiring separate configuration and maintenance. Gigapipe collapses all five into one binary. One deployment, one storage backend, automatic correlation between data types [README][website][5].

Versus SigNoz. SigNoz (26K stars, 2K forks) is the closest comparable project — OpenTelemetry-native, ClickHouse-backed, covers metrics/logs/traces in one product [4]. The meaningful differences: SigNoz has a much larger community and better documentation, but it’s more opinionated about OpenTelemetry as the exclusive ingestion path. Gigapipe is more promiscuous — it accepts Datadog agents, Elastic, InfluxDB, Prometheus scrapers, and Loki shippers without any middleware. If your existing stack already talks one of those protocols, Gigapipe costs zero migration effort [README].

Versus OpenObserve. OpenObserve (18K stars) also promises low storage costs and covers logs/metrics/traces [4]. It has a cleaner UI and more mature documentation. Gigapipe’s edge is the API compatibility layer — OpenObserve has its own ingestion format and query language in addition to OTel support; Gigapipe is deliberately invisible, designed to look exactly like the tool it’s replacing [README][4].

The practical translation: pick Gigapipe if you’re trying to escape Grafana Cloud or Datadog without touching your existing agents. Pick SigNoz if you’re starting fresh and want a larger community. Pick OpenObserve if you want lower storage costs and are willing to spend time on migration.

---

Features

Based on the README and website content:

Ingestion (what it accepts):

• OpenTelemetry (any format — logs, metrics, traces) via official OTel collector integration [README]
• Native Loki push API [README]
• Native Prometheus remote write [README]
• Tempo/Zipkin trace ingestion [README]
• Pyroscope profiling ingestion [README]
• Datadog agent format [README]
• InfluxDB line protocol [README]
• Elastic bulk format [README]

Query (what you can ask it):

• LogQL — the Loki query language for logs [README]
• PromQL — via WASM implementation, compatible with any Prometheus client [README]
• TraceQL — Tempo’s trace query language [README]
• Grafana datasource compatibility out of the box (Loki, Prometheus, Tempo datasources all work) [README]

Storage:

• ClickHouse (primary OLAP engine) [README][website]
• DuckDB (alternative for lighter deployments) [README]
• GigAPI with S3 object storage for cloud-native setups [README]

Visualization:

• Built-in explorer UI (View) — works without Grafana [README]
• Native Grafana datasource support — no plugins needed [README]

What’s notably absent: no session replay, no error tracking a la Sentry, no AI-powered analysis, no alerting built in (you use Grafana for that). This is a storage and query engine, not a full observability product. If you want anomaly detection or root cause analysis baked in, look at Coroot or HyperDX instead [4].

---

Pricing: SaaS vs self-hosted math

Gigapipe Cloud: The website advertises flat-rate pricing with “zero monthly surprises” and explicitly calls out “unmetered” ingestion [website]. Specific tier prices aren’t in the scraped data — check the pricing page at https://gigapipe.com/pricing directly. The model is described as one rate based on data volume, not per-query, per-user, or per-ingestion-event [5][website].

Self-hosted (OSS):

• Software: $0 (AGPL-3.0)
• Hardware: a machine with ClickHouse running on it. ClickHouse works on a $10–20/mo VPS for small workloads; serious production use needs more RAM and fast storage (NVMe is recommended) [website][README]
• Time: non-trivial — see Deployment section

Datadog for comparison [5]:

• Infrastructure monitoring, log management, APM, profiling — all billed separately
• Common outcome for growing startups: bills reach $1,000–$5,000+/mo at scale
• The Vantage.sh comparison cited in the Gigapipe blog [5] details how free-tier entry leads to rapid cost escalation

Grafana Cloud for comparison [5]:

• Free tier exists but limits ingestion rates and retention
• Paid plans scale with ingestion volume, users, and retention period
• Growing engineering orgs regularly report $500–$2,000/mo at moderate data volumes

Self-hosted savings: if you’re currently paying $500/mo for Datadog or Grafana Cloud and have a technical person to deploy and maintain the stack, Gigapipe self-hosted realistically costs $50–150/mo in hardware depending on data volume. That’s roughly $4,000–$5,500/year reclaimed — but only if someone on your team can operate it. If you can’t maintain a ClickHouse instance, the savings don’t materialize.

---

Deployment reality check

Gigapipe is not a tool for non-technical founders. The README says “setup & deploy using the documentation” and points to a Matrix room for help [README]. There’s no one-click installer, no managed Kubernetes operator with pretty docs, no “deploy to Railway” button.

What you actually need:

• A Linux server with Docker
• ClickHouse installed and running (or Docker Compose setup that includes it)
• A reverse proxy for HTTPS
• Familiarity with how Loki, Prometheus, or OTel agents are configured — because you’ll need to change their endpoints to point at Gigapipe

What can go sideways:

• The project was recently renamed from qryn to Gigapipe. Searching for help online turns up old qryn documentation and forum threads, which adds confusion about whether advice is current [about page][README].
• With 89 forks and 1,644 stars, the community is small. If you hit an edge case, the Matrix room is your primary option — there’s no large Stack Overflow presence [README][2].
• ClickHouse itself is a serious piece of infrastructure with its own operational complexity: memory tuning, disk provisioning, backup procedures. You’re not just deploying Gigapipe, you’re deploying Gigapipe plus ClickHouse [README].
• AGPL-3.0 has implications if you’re building a commercial product on top of Gigapipe — any derivative work must also be open-sourced. For internal use or self-hosting, this doesn’t matter. But if you planned to build a SaaS on top of it, get legal advice first.

Realistic time estimate for an experienced DevOps engineer: 2–4 hours to a working instance replacing an existing Loki+Prometheus+Tempo stack. For a developer less familiar with observability infrastructure: 1–2 days including understanding ClickHouse and debugging ingest issues. For a non-technical founder: not recommended without a dedicated infrastructure person or a managed deployment service.

---

Pros and cons

Pros

• True polyglot ingestion. No agents to swap, no SDKs to update. If your stack writes to Loki, Prometheus, Tempo, Pyroscope, Datadog, Elastic, or Influx — it works with Gigapipe today [README].
• Single deployment replaces five. The full Grafana LGTM stack (Loki + Mimir + Tempo + Pyroscope + Grafana) is five services with separate storage. Gigapipe collapses them into one [README][website][5].
• Flat-rate pricing on the managed cloud. No per-ingestion or per-query fees. Incident at 3am that generates 10x normal log volume? Same bill [5][website].
• AGPL-3.0, no open core. The entire feature set is in the open repository — no enterprise tier gating the features you actually need [website][README].
• ClickHouse backend. Fast, proven columnar storage used by multiple production observability systems. Not an experiment [README][website].
• Native Grafana compatibility. Existing dashboards, alerts, and datasource configs work without modification [README].
• Automatic data correlation. Logs, metrics, traces, and profiles in one database means you can correlate across types without ETL [website][5].

Cons

• Small community. 1,644 stars vs. SigNoz (26K), OpenObserve (18K), HyperDX (9K) [2][3][4]. Fewer Stack Overflow answers, fewer blog tutorials, fewer production case studies.
• The qryn rename adds confusion. Searching for help often surfaces outdated qryn documentation [about page]. The rebrand is incomplete in terms of web presence.
• Requires ClickHouse operational knowledge. ClickHouse is powerful but not simple — you’re taking on its operational complexity as part of the deal [README].
• No built-in alerting. You still need Grafana or another tool for alerting. Gigapipe is a backend, not a full platform [README].
• AGPL-3.0 matters for some use cases. Not MIT. Commercial use in products must open-source derivatives [README].
• No session replay, no error tracking. If you need those capabilities (HyperDX has them), Gigapipe isn’t a complete replacement for tools like Datadog or Sentry [4].
• Limited third-party reviews. Unlike Activepieces or SigNoz, there are no independent Trustpilot reviews, G2 ratings, or editorial assessments of Gigapipe in the research available. The blog content is all self-published [5]. This makes it harder to verify claims about reliability and performance at scale.

---

Who should use this / who shouldn’t

Use Gigapipe if:

• You’re running the Grafana LGTM stack self-hosted and want to cut operational complexity — Gigapipe is a direct drop-in that your existing agents already speak.
• You’re paying Datadog or Grafana Cloud for logs + metrics + traces and have someone who can manage infrastructure. The self-hosted math works out.
• You need to ingest from multiple protocol families (Prometheus scrapers AND Datadog agents AND OTel collectors) without middleware.
• Flat-rate pricing matters more to you than a large support ecosystem.

Skip it (pick SigNoz instead) if:

• You want a larger community, better documentation, and more third-party tutorials.
• You’re starting fresh with OpenTelemetry and don’t need backward compatibility with older agent formats.
• You want active GitHub discussion and a bigger contributor base to trust the project’s longevity.

Skip it (pick OpenObserve instead) if:

• Storage cost is the primary concern — OpenObserve specifically optimizes for low storage costs at petabyte scale [4].
• You want a cleaner UI and more polished user experience out of the box.

Skip it (stay on Grafana Cloud) if:

• Your team doesn’t have infrastructure experience to run ClickHouse in production.
• Your compliance requirements require a managed, SLA-backed observability service.
• You’re below $200/mo on your current bill — the migration cost won’t pay off.

Skip it (pick Coroot instead) if:

• You want zero-instrumentation observability via eBPF — Coroot doesn’t require you to touch your application code at all [4].

---

Alternatives worth considering

• SigNoz — 26K stars, OpenTelemetry-native, ClickHouse-backed, logs/metrics/traces in one product. Much larger community than Gigapipe. Start here if you’re evaluating open-source Datadog alternatives [4].
• OpenObserve — 18K stars, claims 140x lower storage costs than Elasticsearch, covers logs/metrics/traces. Better documented than Gigapipe [2][4].
• HyperDX — 9K stars, full-stack observability including session replay and error clustering. Better fit if you need Datadog feature parity [4].
• Coroot — 7K stars, eBPF-based zero-instrumentation observability. No code changes required to start seeing metrics, traces, and profiling [4].
• Grafana Cloud (LGTM) — the managed version of the stack Gigapipe replaces. Higher cost but professional support and SLAs [5].
• Datadog — the incumbent. Most features, highest cost, fully closed source. The thing people are usually running from.
• Uptrace — 4K stars, OpenTelemetry-based, integrates traces/metrics/logs. Less known but targets the same space [2].

---

Bottom line

Gigapipe solves a specific, real problem: the Grafana LGTM stack is five services you have to deploy, configure, and maintain — and the managed alternative (Grafana Cloud, Datadog) charges unpredictably for the privilege. Gigapipe’s answer is one deployment that speaks the same protocols, backed by ClickHouse, with flat-rate pricing on the cloud tier and a fully open AGPL-3.0 license. The architecture is sound and the compatibility story is genuinely differentiated — there’s no other self-hosted project that transparently accepts Loki, Prometheus, Tempo, Pyroscope, Datadog, InfluxDB, and Elastic ingest simultaneously without a proxy in front.

The honest caveat is the community size. At 1,644 stars, Gigapipe is an indie underdog in a category with multiple well-funded competitors. If something breaks in production, your resources are the documentation, a Matrix room, and the source code — there’s no large forum thread to fall back on. For teams with infrastructure experience who are currently running the LGTM stack and want to consolidate it, or who are escaping Datadog and have existing agents they don’t want to reconfigure, Gigapipe is worth serious evaluation. For everyone else, start with SigNoz.

---

Sources

1. OpenAlternative — Open Source Projects tagged “Monitoring” — https://openalternative.co/tags/monitoring
2. OpenAlternative — Open Source Projects tagged “Logs” (includes Gigapipe listing: 1,659 stars, 89 forks) — https://openalternative.co/tags/logs
3. OpenAlternative — Open Source Projects tagged “Prometheus” (includes Gigapipe listing) — https://openalternative.co/tags/prometheus
4. OpenAlternative — Open Source Projects tagged “Observability” — https://openalternative.co/tags/observability
5. Alex Maitland, Gigapipe Blog — “Gigapipe: Unveiling Cloud Observability Costs” — https://blog.gigapipe.com/the-hidden-costs-of-cloud-observability-why-gigapipe-stands-out

Primary sources:

• GitHub repository and README: https://github.com/metrico/gigapipe (1,644 stars, AGPL-3.0)
• Official website: https://gigapipe.com
• About page: https://gigapipe.com/about
• Pricing page: https://gigapipe.com/pricing
• Documentation: https://gigapipe.com/docs/oss