SketchLog
Bounded-memory telemetry for observability
Start new thread

SketchLog - Bounded-memory telemetry for observability

by•
SketchLog is an open-source observability platform for compact telemetry summaries. It uses sketch data structures to answer production questions like p95/p99 latency, unique users, top events, anomaly movement, SLO burn, and streaming SQL without storing every raw event forever. It includes a hosted playground, dashboards, PostgreSQL durability, optional OmniKV embedded storage, SDKs, WebAssembly, Docker, Helm, Kubernetes docs, and proof-first CI/release checks.

Add a comment

Replies

Best
Maker
📌
Hi Product Hunt, I’m Bala, the founder of SketchLog. I built SketchLog because modern systems generate more telemetry than teams can afford to store forever as raw events. But many production questions do not require every raw event. Teams often need fast answers like p99 latency, unique users, top events, anomaly movement, SLO burn, or release impact. SketchLog uses bounded-memory sketch data structures such as DDSketch, HyperLogLog-style cardinality, and Count-Min-style frequency tracking to keep compact, mergeable telemetry summaries. It is not meant to replace Prometheus, Grafana, Loki, Datadog, New Relic, TimescaleDB, or data warehouses. It is designed to work beside them. This launch includes a hosted playground, dashboards, Streaming SQL examples, PostgreSQL-backed durability, optional OmniKV embedded storage, SDKs, WebAssembly, Docker, Helm, Kubernetes docs, and proof scripts for storage and telemetry load behavior. I would love feedback from observability engineers, SREs, platform engineers, database people, and open-source builders. What would you want to see before trusting a bounded-memory telemetry system in production?

One thing I'd love to see is a built-in cost estimator that shows how much storage and compute each sketch configuration would consume before you deploy it, especially since the whole pitch is about not storing every raw event.

Maker

 Thanks, this is a very good point. A built-in cost estimator fits SketchLog really well because bounded-memory telemetry should be understandable before deployment, not only after running it.

I’m thinking of adding a calculator that estimates memory, storage, and compute based on stream count, sketch accuracy, retention windows, tenants, and backend choice. This would make the “why not store every raw event?” tradeoff much more concrete.

A hosted tier with a free usage cap beyond the playground would be a nice way to actually try SketchLog on real traffic before committing to self hosting. Right now jumping from the demo straight to Kubernetes feels like a big leap.

Maker

 I agree. The hosted playground is useful for understanding the workflows, but a small hosted tier with a free usage cap would make it much easier to test SketchLog on real traffic.

Right now the project is focused on open-source/self-hosted proof paths, but a hosted evaluation tier is definitely one of the most important next steps.

Loaded up the playground and ran a streaming SQL query against some sample telemetry, the response time felt surprisingly snappy for sketch-based storage. Curious how it holds up once I point our own SDKs at it on a real workload.

Maker

 Thank you for trying it. That is exactly the direction I want SketchLog to go: fast operational questions over compact telemetry summaries.

The next thing I want to prove more deeply is behavior under real SDK-driven workloads, including sustained ingestion, query latency, storage backend differences, and memory usage over time.