Move from a percentile to the slow requests
Use PromQL for service-level trends and TraceQL for the exact spans behind a regression
REQUEST TO RUNTIME
Application observability
On open standards
Send application metrics, logs, traces and profiles over OpenTelemetry. Keep instrumentation portable and let PulsusDB expose the query languages already used by your dashboards and engineers
application.observabilityOTEL IN · OPEN QUERIES OUT
APPLICATION ESTATE OTel SDKsAuto-instrumentationStructured logsContinuous profiles
STATELESS PULSUSDB
Ingest APIsnormalise · batch · route
Query compilersPromQL · LogQL · TraceQL
STATEFUL DATABASE ClickHouse® database signal-aware schemas
rollups · tiering · scale
rollups · tiering · scale
Complex work is pushed down to the dataReduced results return
01RED metrics02Application logs03Distributed traces04Runtime profiles
What this lets you investigate
Keep the operational question
Close to the data
PulsusDB keeps the collection and query surfaces open. The ClickHouse database handles high-volume storage and analytical execution while the signal-specific query language preserves the workflow your team already knows
Keep the exception and its surrounding log context
Use trace and span identifiers in structured logs to move between a failed request and its application output
Retain high-cardinality telemetry efficiently
Signal-specific schemas, compression codecs and object storage tiering reduce the cost of keeping detailed history
Three signals Three query languages
Ask the question
In its native language
PulsusDB compiles familiar observability queries into efficient database work, pushes filters and aggregation toward the ClickHouse database tier and returns only the result needed by the client
PromQL01 / ERROR RATIO
sum(rate(http_server_request_duration_seconds_count{http_response_status_code=~"5.."}[5m]))
/
sum(rate(http_server_request_duration_seconds_count[5m]))Calculate a service error ratio using the same PromQL dashboards already expect
LogQL02 / CHECKOUT ERRORS
{service_name="checkout",
deployment_environment="production"}
| json
| level="error"Parse structured application logs after the service stream has been resolved
TraceQL03 / CRITICAL PATH
{ resource.service.name = "checkout"
&& status = error }
| by(.service.name)Search failed request paths while retaining service boundaries
One architecture underneath
Optimised for the signal
Unified at the platform
Metrics, logs, traces and profiles do not have the same read path. PulsusDB gives each one a purpose-built physical model, then exposes a consistent OpenTelemetry ingest layer and familiar query APIs above it
Explore the architecture →Signal-specific models
Ordering keys, indexes, codecs and projections follow the dominant query shape for each signal
Stateless application tier
Scale ingest and query processes independently while durable state remains in the database tier
Efficient long retention
Compression, materialised rollups and object storage tiering reduce the cost of detailed operational history
Open client workflows
Use OpenTelemetry for ingest and PromQL, LogQL or TraceQL for investigation
OPEN SOURCE · AGPLV3Bring the telemetry
Bring the telemetry
Keep the query language
Start with the workload in front of you, then add the rest of the estate without adding another observability backend