o11ykit
o11ytracesdb engine

A distributed traces database
that runs in your browser.

SQLite for observability — embedded, serverless, zero network calls.

Store hundreds of thousands of OpenTelemetry spans at <30 bytes/span using columnar compression and dictionary encoding. Query with structural operators, explore with bloom-accelerated lookups, and visualize waterfalls — all client-side. No backend required.

10–15× Less memory vs JS objects
90%+ String compression via dictionaries
O(1) Structural queries via nested sets
Learn How It Works Browse Source

How It Works

o11ytracesdb stores OpenTelemetry spans in a columnar layout optimized for the browser. Dictionary encoding collapses repetitive strings (service names, operations, HTTP methods) to 8–16 bit integers — a 90%+ reduction. Nested set encoding turns parent-child relationships into integer indices in typed arrays, making structural queries a simple array comparison instead of tree traversal. Bloom filters accelerate trace ID lookups to O(1).

Ingest OTLP spans
→
Encode Dictionary + columnar
→
Index Bloom + nested set
→
Query Structural DSL

Not a backend replacement. o11ytracesdb sits after Tempo, Jaeger, or Datadog — inside your UI. It complements server-side stores by eliminating round-trips: brush-select a metric spike, instantly filter correlated traces and logs in local memory, zero network calls.

The Problem

🔄

Every click round-trips

Existing observability UIs re-fetch data from the server on every pan, zoom, and filter. Click an exemplar? That's a network call to Tempo. Drill into a trace? Another call.

💥

Browsers crash at scale

JS object overhead of 30–50 bytes per data point means dashboards routinely OOM. Kibana and Grafana both struggle with large trace datasets in the browser.

🔗

Cross-signal is 3+ hops

Correlating a metric spike → traces → logs requires 3+ sequential API calls with server-side credentials. What should be instant takes seconds.

The fix: store spans in columnar typed arrays at <30 bytes each, index with bloom filters and nested sets, and query locally. Metric spike → correlated traces → filtered logs in one frame. Demo it yourself below ↓

Choose a Scenario

Select a pre-built trace scenario to generate, or configure your own. Each creates realistic distributed traces with multiple services, varying depths, and configurable error rates.