See pressure before it becomes application latency
Track connections, locks, cache behaviour, replication and storage metrics with PromQL over long histories
CLIENT TO QUERY
Database monitoring
With request context
Bring database metrics, server logs and client spans into the same observability platform. Investigate saturation, errors and slow operations without giving up PromQL, LogQL or TraceQL
databases.observabilityOTEL IN · OPEN QUERIES OUT
DATABASE FLEET Database receiversServer logsClient instrumentationHost metrics
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
01Engine metrics02Query logs03Client spans04Host telemetry
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
Find the service behind a slow database call
Trace instrumented client operations with database system, namespace and operation attributes preserved
Search server logs around the exact failure window
Use LogQL labels and word indexing to reduce the database log volume before the detailed pipeline runs
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 / CONNECTION PRESSURE
max by (db_system, server_address) (
db_client_connections_usage{state="used"}
)Compare connection usage across engines and instances using a common metric model
LogQL02 / LOCK TIMEOUTS
{service_name="postgres",
deployment_environment="production"}
|= "lock timeout"Search a precise failure phrase inside the selected database log streams
TraceQL03 / SLOW QUERIES
{ span.db.system = "postgresql"
&& span.db.operation.name = "SELECT"
&& duration > 500ms }Find slow client spans by database system and operation without exposing statement text in the query
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