I just released SketchLog v1.2.5.
SketchLog is an open-source observability project built around a simple idea:
Telemetry systems should not need unlimited raw-event storage to answer useful production questions.
Modern systems generate huge volumes of metrics, logs, events, traces, and service signals. Storing everything forever is expensive, and querying raw history can become slow or operationally painful.
SketchLog takes a different approach.
Instead of keeping every raw event as the primary source for every question, SketchLog uses bounded-memory sketch data structures to summarize telemetry streams while still supporting practical operational analytics.
What SketchLog is trying to solve
In production systems, teams often need answers like:
What is the current p99 latency?
How many unique users or services appeared in this window?
Which events are happening most often?
Did this release change the latency distribution?
Is an SLO burning faster than expected?
Can we compare two windows without scanning all raw events?
Traditional observability systems are excellent, but high-cardinality and high-volume telemetry can become expensive quickly.
SketchLog is not trying to replace Prometheus, Grafana, Loki, Datadog, New Relic, TimescaleDB, InfluxDB, Mimir, Thanos, or a data warehouse.
It is designed to work beside them.
Use existing systems for raw history, deep label indexing, dashboards, logs, traces, and long-term analysis.
Use SketchLog when you want compact, mergeable, bounded-memory summaries for fast operational questions.
The core idea: compact telemetry summaries
At the center of SketchLog are sketch data structures.
Sketches are probabilistic data structures that trade exact raw storage for compact approximate answers with useful guarantees.
SketchLog includes:
DDSketch for percentile estimation
HyperLogLog-style cardinality estimation
Count-Min Sketch-style frequency tracking
mergeable sketch state
bounded sparse stores
streaming summaries across windows and namespaces
This makes it possible to keep useful signals like p50, p95, p99, unique counts, and top events without retaining every individual event forever.
What is new in v1.2.5
This release focuses on making SketchLog easier to evaluate as a real product, not just a GitHub repository.
Highlights include:
polished hosted playground
stronger public website positioning
improved README and documentation
storage backend proof documentation
PostgreSQL durability path
optional OmniKV embedded storage path
realistic telemetry load proof
Docker smoke verification
package publishing improvements
Python, TypeScript, React, Go, and WebAssembly surfaces
Helm, Docker, and Kubernetes documentation
release and CI hardening
The goal was to make the project easier to understand, easier to try, and easier to verify.
Hosted playground
The hosted playground is now the fastest way to try SketchLog.
You can open it in a browser without installing anything:
https://sbalavignesh123.github.io/sketchlog/demo/
The playground includes:
guided product tour
live dashboard view
DDSketch percentile estimation
cardinality and frequency examples
Streaming SQL examples
stream operations
exporter payload previews
storage proof commands
PostgreSQL and OmniKV backend explanations
It runs as a static browser demo, so it does not require API keys, a backend, or local setup.
Streaming SQL
SketchLog also includes Streaming SQL examples for asking operational questions over telemetry streams.
For example, you can reason about:
latency grouped by service
approximate unique users
top events
window comparisons
anomaly movement
SLO burn signals
The goal is to make telemetry summaries queryable, not just stored.
Storage backends
SketchLog supports multiple storage paths depending on how you want to run it.
In-memory
Useful for demos, tests, quick experiments, and ephemeral workflows.
PostgreSQL
PostgreSQL-backed storage is the durable server deployment path.
It is useful when you want SketchLog state persisted in a familiar production database.
OmniKV
OmniKV is an optional embedded storage backend.
This is useful for local-first, edge, and single-node deployments where running a separate database service may be too heavy.
The idea is not that every user must use OmniKV. It is available as an embedded option when it fits the deployment model.
Integrations
SketchLog is designed to fit into existing observability workflows.
Current and documented integration paths include:
OpenTelemetry
Prometheus
Grafana
Loki
Datadog
New Relic
Docker
Helm
Kubernetes
WebAssembly
Python SDK
TypeScript SDK
React dashboard SDK
Go client
The goal is to make SketchLog useful beside existing tools, not isolated from them.
Proof-first engineering
One thing I care about deeply is not just saying “production-ready.”
Production readiness has to be earned through evidence.
SketchLog includes proof and validation paths such as:
Docker smoke checks
PostgreSQL durability proof
OmniKV storage proof
realistic telemetry load proof
CI matrix testing
branch coverage
package checks
wheel validation
release smoke tests
documentation checks
security scanning
This does not mean SketchLog is perfect.
It is still an open-source beta.
But the project is moving in a proof-first direction: if something is claimed, there should be a way to test it.
Why I built this
I wanted to explore a different way of thinking about telemetry.
Raw events are valuable, but not every operational question requires storing every event forever.
For many production questions, compact summaries are enough:
how bad is tail latency?
how many unique users were affected?
what changed after deployment?
which events dominate the stream?
is this service drifting from normal behavior?
SketchLog is my attempt to build that idea into an open-source platform.
Try it
GitHub:
https://github.com/SBALAVIGNESH123/sketchlog
Website:
https://sbalavignesh123.github.io/sketchlog/
Hosted playground:
https://sbalavignesh123.github.io/sketchlog/demo/
Documentation:
https://sbalavignesh123.github.io/sketchlog/docs/
If you work on observability, SRE, platform engineering, telemetry pipelines, distributed systems, or databases, I would love your feedback.
What would you want to see before trusting a bounded-memory telemetry system in production?
