How are you different than Signoz, another YC company that also does Observability using clickhouse ?
Echoing the comment below, I guess one obvious thing is that we are a team at ClickHouse and an official first-party product on top. That translates into: - We're flexible on top of any ClickHouse instance, you can use virtually any schema in ClickHouse and things will still work. Custom schemas are pretty important for either tuned high performance or once you're at a scale like Anthropic. This makes it also incredi…
> an official first-party product on top
So, seems like the direction you are going is trying to enable ingestion to different ClickHouse instances (Cloud/BYOC/Self hosted) and then use HyperDX as the query & visualization layer on top.
I think, fundamental difference we have at SigNoz on how we approach this is that we want to solve for observability and the fact that we use ClickHouse today is just a point in time fact. In future, we are open to use any other datastore which may be more performant for observability. We can also use different databases to augment different use cases in observability.
>Ultimately from a product philosophy standpoint, we aren't big believers in the "3 pillars" concept, which tends to manifest as 3 silos/tabs for "logs", "metrics", "traces" (this isn't just SigNoz - but across the industry).
I am not too sure on how this works in practice, do you expect people to write metrics and logs query in the same explorer. From our experience, the query writing experience is very different for logs and metrics and you need different defaults to make the query writing UX easier for users.
Though I agree, the ability to query across signals is an important point and we are already doing work on this at SigNoz (https://signoz.io/blog/observability-requires-querying-acros...).