Introducing SketchLog v1.2.5: Bounded-Memory Telemetry for Observability

S Bala Vignesh — Fri, 17 Jul 2026 11:24:49 +0000

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?

built a 24K-line transactional SQL engine from scratch in Rust—no RocksDB/SQLite wrappers. From sharded memtables to a cost-based optimizer and SSI, here is how I designed it: https://github.com/SBALAVIGNESH123/OmniKV

S Bala Vignesh — Fri, 05 Jun 2026 12:01:32 +0000

GitHub - SBALAVIGNESH123/OmniKV: Distributed transactional SQL + KV engine. PostgreSQL wire protocol. Raft consensus. Cost-based optimizer. 290 tests. 20K lines of Rust. From scratch. · GitHub

Distributed transactional SQL + KV engine. PostgreSQL wire protocol. Raft consensus. Cost-based optimizer. 290 tests. 20K lines of Rust. From scratch. - SBALAVIGNESH123/OmniKV

github.com

DEV Community: S Bala Vignesh

Introducing SketchLog v1.2.5: Bounded-Memory Telemetry for Observability

built a 24K-line transactional SQL engine from scratch in Rust—no RocksDB/SQLite wrappers. From sharded memtables to a cost-based optimizer and SSI, here is how I designed it: https://github.com/SBALAVIGNESH123/OmniKV

GitHub - SBALAVIGNESH123/OmniKV: Distributed transactional SQL + KV engine. PostgreSQL wire protocol. Raft consensus. Cost-based optimizer. 290 tests. 20K lines of Rust. From scratch. · GitHub