ClickHouse

ClickStack

TypeScript2023–2026

ClickHouse / ClickStack

ClickStack

Resolve production issues, fast. An open source observability platform unifying session replays, logs, metrics, traces and errors powered by ClickHouse and OpenTelemetry.

Explore on GitHub Read Hacker News discussions

7Distinct people

23Mentions

0Explicit recommenders

10KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Resolve production issues, fast. An open source observability platform unifying session replays, logs, metrics, traces and errors powered by ClickHouse and OpenTelemetry.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year23 dated mentions

Observed mentions: 2023-09-18 16:25:10 UTC to 2026-10-08 19:28:04 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	12	1	11
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	6	3	3
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	4	2	2
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	0	1

What Hacker News says

12 sources

mikeshi42·Nov 16, 2023

Biased as a founder in the space [1] but I think with OpenTelemetry + OSS extensible observability tooling, the holy grail of one tool is more realizable than ever. Vendor lock in with Otel now is hopefully a thing of the past - but now that more obs solutions are going open source, hopefully it's not necessarily true that one tool would be mediocre over all use cases (since DD and the likes are inherently limited by their own engineering teams, vs OSS products can have community/customer contributions to improve the surface area over time on top of the core maintainer's work). [1] https://github.com/hyperdxio/hyperdx

In Migrating to OpenTelemetry

mikeshi42·Nov 2, 2023

HyperDX (YC S22) | Founding Engineer | SF Bay Area HQ | REMOTE We're building an open source, dev friendly observability tool (think Datadog, but something developers actually love to use and companies can actually afford). We're in the intersection of needing to build rock solid infrastructure ingesting TBs of data, searching it incredibly quickly and scalably, and layering on top a buttery smooth DX from our language-specific SDKs, APIs and web app. We're super early and hiring our first founding engineer. We already have a cloud product customers pay for and love, loads of runway regardless of the wider economy, 5k+ Github stars weeks after our OSS launch, and tons of hard technical problems. The vast majority of our work is open source, so you can get a sense of what you'd be working with here: https://github.com/hyperdxio/hyperdx Our

Read the rest

job listing is here as well: https://www.ycombinator.com/companies/hyperdx/jobs/zFXTbzl-f... Come by our discord as well if you just want to talk shop: https://discord.gg/FErRRKU78j I'm Mike, one of the cofounders. If you love shipping quickly and want to help us build from the ground up an open source developer tool (that devs won't hate when they're on-call), let me know! mike [at] hyperdx.io

In Ask HN: Who is hiring? (November 2023)

mikeshi42·Oct 31, 2023

Oh huh! What would you do with span start independent of stops? A tangent on logcat - local observability to me is a really intriguing area, I think there's a story of Otel for local as well if someone can build a good enough local DX for consuming them (we've been told a number of times about this https://github.com/hyperdxio/hyperdx/issues/7 as an example)

In Vendor lock-in in the observability space

mikeshi42·Sep 26, 2023

> I mean no slander or disrespect to anyone involved, but there was a DataDog alternative posted sometime in the last few weeks that had a docker-compose with like 15 containers in it. If this was us [1] (an OSS Datadog alternative posted last week :D ), we do have quite a bit (11, 2 are optional) but we're working on bringing it down. We currently split our ingestion pipeline into 3 independently scalable bits, but we can probably bring it down into 1 for any small-scale deployment. Otherwise we do have the standard need for a cache (redis), db (mongo), main storage (clickhouse), and then the standard API server + frontend, and a separate task to run alerts. There's likely a few more things we can merge together, but it comes at the expense of making it unscalable to workloads typical to a company and divergence in the code base, which o

Read the rest

verall doesn't seem like the right tradeoff. Imo the real concern as someone that personally owns too many tiny VM instances is resource footprint - which can be tuned down to ~1GB of memory for us (depending on server load). Feel free to open an issue too if you think there's something we can adjust there as well. [1] https://github.com/hyperdxio/hyperdx

In Show HN: Bigcapital - A open-source alternative to QuickBooks

mikeshi42·Sep 21, 2023

We're[1] building the OSS equivalent when it comes to the observability side of Splunk/DD, on Clickhouse naturally of course but believe in the same end goal of lowering cost via separation of compute and storage. [1] https://github.com/hyperdxio/hyperdx

In Cisco Acquires Splunk

mikeshi42·Sep 21, 2023

I think we fit in that bucket [1] - open source, self-hostable, based on OpenTelemetry and backed by Clickhouse DB (columnar, not time-series). Clickhouse gives users much greater flexibility in tradeoffs than either a time-series or inverted-index based store could offer (along with S3 support). There's nothing like a system that can balance high performance AND (usable) high cardinality. [1] https://github.com/hyperdxio/hyperdx disclaimer (in case anyone just skimmed): I'm one of the authors of HyperDX

In Tracing: Structured logging, but better

alexisread·Sep 20, 2023

Any of the Clickhouse-based Otel stores can dump the traces to s3 for long-term storage, and can be self-hosted. I know the following use CH: https://uptrace.dev/ https://signoz.io/ https://github.com/hyperdxio/hyperdx

In Tracing: Structured logging, but better

alexisread·Sep 20, 2023

Any of the Clickhouse-based Otel stores can do event sourcing - just set up materialised views on the trace tables. I know the following use CH: https://uptrace.dev/ https://signoz.io/ https://github.com/hyperdxio/hyperdx

In Tracing: Structured logging, but better

mikeshi42·Sep 19, 2023

Definitely, we want to make it easy to integrate arbitrary email providers instead of whatever vendor we happened to have integrated natively right now. It's not an intentional paid feature gate as much as it's just something we didn't get time to put in an OSS-ready workflow for the OSS launch. We're thinking of being able to allow users to create a custom webhook alert so you can get full flexibility on what vendor you use and how the alert should be crafted, would love to hear your feedback there, though may need to ship some stopgap solutions depending on demand! https://github.com/hyperdxio/hyperdx/issues/2

In Show HN: HyperDX – open-source dev-friendly Datadog alternative

mikeshi42·Sep 19, 2023

Since my comment is too old to edit now - musing on this a bit more I think this would be pretty awesome to turn into a well-supported workflow to have a low-resource-usage/all-in-one version for just local development. If anyone wants to chat more about this - I've kicked off an issue [1] to gather interest and everyone's feedback. [1] https://github.com/hyperdxio/hyperdx/issues/7

In Show HN: HyperDX – open-source dev-friendly Datadog alternative

specialist·Sep 18, 2023

First paragraph https://github.com/hyperdxio/hyperdx "HyperDX helps engineers figure out why production is broken faster by centralizing and correlating logs, metrics, traces, exceptions and session replays in one place. An open source and developer-friendly alternative to Datadog and New Relic." Just perfect. Bravo. -- As a merc, I never understood the why of Datadog (or equiv). The teams and projects I rotated thru each embraced the "LOG ALL THE THINGS!" strategy. No guiding purpose, no esthetics. General agreement about need to improve signal to noise ratio. But little courage or gumption to act. And any such efforts would be easily rebuffed by citing the parable of Chesterfordstorm's Fences of Doom and something something about velocity. Late last century, IT projects, like CRMs and ERPs, were plagued by over collection of data. Opaqu

Read the rest

e provenance, dubious (data) quality, unclear ownership, subtractive value propositions (where the whole is worth less than the parts). No, no, don't remove that field. We might need it some day. Today's "analytics" projects are the same, right? Every drive-by stakeholder tosses in a few tags, some misc fields, a little extra meta. And before anyone can say "kanban", the stone soup accreted enough mass to become a gravity well threatening implosion dragging the entire org-chart into the gapping maw of our universe's newest black hole. Am I wrong? But logging is useful, right? Or at least has that potential. The last time I designed a system end-to-end, that's kinda what we did. Listed all the kinds of things we wanted to log. Sorta settled on formats and content (never really ever done). Did regular log bashs to explain and clear anomalies. Scripts for grooming and archiving. (For one team I rotated thru, most of their spend was on just cloudwatch. Hysterical.) But my stuff wasn't B2C, so wasn't tainted by the attention economy, manufactured outrage, or recommenders. No tags, referrers, campaigns, etc. It was just about keeping the system up and true. And resolving customer support incidents asap. Does any one talk or write about this? (Those SRE themed novels are now buried deep in my to read pile.) I'd like some cookbooks or blue prints which show some idealized logging strategies, with depictions of common enough troubleshooting scenarios. Having something authoritative to cite could reduce my semblance to an Eeyore. "Hey, team mates, you know what'd be really great?! Correlation IDs! So we can see how an action percolates thru our system!" Just curious. PS- Datadog's server hexagon map/chart thingie is something else. The kind of innovation that wins prizes.

In Show HN: HyperDX – open-source dev-friendly Datadog alternative

mikeshi42·Sep 18, 2023Submission

Show HN: HyperDX – open-source dev-friendly Datadog alternative

Hi HN, Mike and Warren here! We've been building HyperDX (hyperdx.io). HyperDX allows you to easily search and correlate logs, traces, metrics (alpha), and session replays all in one place. For example, if a user reports a bug “this button doesn't work," an engineer can play back what the user was doing in their browser and trace API calls back to the backend logs for that specific request, all from a single view. Github Repo: https://github.com/hyperdxio/hyperdx Coming from an observability nerd background, with Warren being SRE #1 at his last startup and me previously leading dev experience at LogDNA/Mezmo, we knew there were gaps in the existing tools we were used to using. Our previous stack of tools like Bugsnag, LogRocket, and Cloudwatch required us to switch between different tools, correlate timestamps (UTC? local?), and manually

Read the rest

cross-check IDs to piece together what was actually happening. This often made meant small issues required hours of frustration to root cause. Other tools like Datadog or New Relic come with high price tags - when estimating costs for Datadog in the past, we found that our Datadog bill would exceed our AWS bill! Other teams have had to adjust their infrastructure just to appease the Datadog pricing model. To build HyperDX, we've centralized all the telemetry in one place by leveraging OpenTelemetry (a CNCF project for standardizing/collecting telemetry) to pull and correlate logs, metrics, traces, and replays. In-app, we can correlate your logs/traces together in one panel by joining everything automatically via trace ids and session ids, so you can go from log <> trace <> replay in the same panel. To keep costs low, we store everything in Clickhouse (w/ S3 backing) to make it extremely affordable to store large amounts of data (compared to Elasticsearch) while still being able to query it efficiently (compared to services like Cloudwatch or Loki), in large part thanks to Clickhouse's bloom filters + columnar layout. On top of that, we've focused on providing a smooth developer experience (the DX in HyperDX!). This includes features like native parsing of JSON logs, full-text search on any log or trace, 2-click alert creation, and SDKs that help you get started with OpenTelemetry faster than the default OpenTelemetry SDKs. I'm excited to share what we've been working with you all and would love to hear your feedback and opinions! Hosted Demo - https://api.hyperdx.io/login/demo Open Source Repo: https://github.com/hyperdxio/hyperdx Landing Page: https://hyperdx.io

722 points · Open discussion