Use OpenTelemetry at the edge
Applications, cloud services and infrastructure send vendor-neutral telemetry through the OpenTelemetry Collector or compatible exporters
OTLP · remote writeOpen observability platform
Observability for
extreme telemetry volumes
PulsusDB receives logs, metrics, traces and profiles through OpenTelemetry, stores them in query-optimised ClickHouse® database models and exposes the PromQL, LogQL and TraceQL interfaces engineers already know
platform.runtimeOPEN INTERFACES · DATABASE-SCALE EXECUTION
INGESTtelemetry in
OTel Collectorlogs · metrics · traces · profiles
OTLP
Ingest APIsvalidate · normalise · batch
INSERT
Signal modelsClickHouse® database
QUERYanswers out
Grafana® software · Persesdashboards · explore · API clients
RESULTS
Query compilersPromQL · LogQL · TraceQL
SQL
SQL executionprune · scan · aggregate
CLIENTSSTATELESS PULSUSDBSTATEFUL CLICKHOUSE® DATABASE
OTLPPROMQLLOGQLTRACEQLPROMETHEUS REMOTE WRITEHTTP APIS
The complete data path
From telemetry production to a query result
PulsusDB concentrates on the data path between the collectors and frontends you already run. Collection, storage layout, query compilation and database execution are designed as one system
Store each signal for its queries
Logs, metrics, spans and profiles use separate ordering keys, indexes, codecs and materialised views instead of a generic event table
Query-optimised schemasPreserve familiar query languages
PromQL, LogQL and TraceQL expressions become typed plans before filters, joins and eligible aggregation are lowered into SQL
Language semantics retainedRun the heavy work beside the data
ClickHouse prunes, scans and aggregates stored columns, then sends a reduced result back across the stateless database boundary
SQL pushdownSignal-aware by design
One platform
Four physical data models
Unified does not mean identical. Each telemetry signal keeps the shape, indexes and query surface that make it useful while sharing one operational database layer
METRICSPROFILES
PromQL
Prometheus-compatible metrics with label-aware series resolution, compressed samples and automatic routing to the most efficient eligible rollup
rate()histogram_quantile()aggregation
Explore metrics → LOGSLogQL
Stream selection, word-indexed search and multi-stage pipelines over retained logs stored in a columnar model built for selective reads
stream selectorspipeline filtersunwrap
Explore logs → TRACESTraceQL
Search spans through indexed resource and span attributes while ClickHouse performs parallel filtering and trace reconstruction across large datasets
attributesstructural operatorsaggregates
Explore traces → Profile APIs
Retain profiling telemetry beside logs, metrics and traces through the OpenTelemetry profiles ingestion path and compatible client APIs
functionsstackssamples
OpenTelemetry profilesThe query language compiler
Familiar expressions become database-native execution plans
The compiler resolves the signal model and time range, selects raw data or an eligible rollup, then pushes complex filters, joins, grouping and aggregation into the ClickHouse database. The stateless tier receives only the rows needed to finish the language semantics
Explore query compilation →promql.queryCOMPILED PLAN
INPUT
histogram_quantile(0.99,
sum by (le, service) (
rate(http_request_duration_seconds_bucket[5m])
)
)parseresolverolluplower
CLICKHOUSE SQL
SELECT service, le, sum(rate_value)
FROM metric_rollup_60s
PREWHERE metric_name = $metric
GROUP BY service, lerollup selected automaticallyreduced result set returned
Why a ClickHouse database backend
The database work is already solved at analytical scale
PulsusDB adds observability protocols, signal-aware schemas and query compilers above a database engine designed for fast analytical queries, sustained ingestion and horizontal growth
Columnar scans
Read only the fields required by the query and process values in vectorised batches
Compression by data type
Use Delta, DoubleDelta, Gorilla and general codecs where each telemetry column benefits
Primary-key pruning
Order signal tables around their common time, identity and attribute access patterns
Materialised rollups
Pre-aggregate metric windows, then route eligible range queries to the most efficient resolution
Horizontal scale
Shard data and execute partial work in parallel while distributed tables combine the result
Object storage tiering
Move older parts to lower-cost object storage while the same ClickHouse tables remain queryable
See how data models, compression, indexes, rollups and distributed execution fit together
Explore the architecture →Independent scaling boundaries
Stateless application tier
Stateful database tier
Start with a single PulsusDB process, then separate reader and writer workloads as demand grows. PulsusDB instances can be restarted, replicated and load-balanced because durable telemetry and distributed execution remain in the ClickHouse database tier
PulsusDB
Ingest APIQuery APIsQuery compilerResult evaluation
Scale readers and writers independentlySQL plans and reduced results
ClickHouse® database
Telemetry tablesIndexes and rollupsDistributed computeDurable storage
Scale storage and compute as the dataset growsFit the stack you already operate
OpenTelemetry in
Existing observability tools out
Connect cloud and application telemetry through OpenTelemetry, then use Grafana® software, Perses and compatible API clients without replacing the query languages your teams know
AWS · AZURE · GCP · KUBERNETES→OTEL→PULSUSDB→QUERY APIS→GRAFANA® SOFTWARE · PERSES