Metrics with PromQL

PulsusDB serves the standard Prometheus HTTP API directly. Existing Prometheus clients and Grafana can use the PulsusDB base URL without a compatibility flag.

Instant query

curl --get 'http://localhost:3100/api/v1/query' \
  --data-urlencode 'query=sum by (service) (rate(http_requests_total[5m]))' \
  --data-urlencode 'time=2026-10-31T12:00:00Z'

Range query

curl --get 'http://localhost:3100/api/v1/query_range' \
  --data-urlencode 'query=histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))' \
  --data-urlencode 'start=2026-10-31T11:00:00Z' \
  --data-urlencode 'end=2026-10-31T12:00:00Z' \
  --data-urlencode 'step=30s'

Discovery and metadata

PulsusDB provides Prometheus-compatible label, series, metadata, and status endpoints. Common clients call these automatically for variable completion and query editors.

Rollup selection

The schema can maintain several metric rollup levels. A range query chooses a level based on its time range and response grid, while preserving selector semantics:

• short, detailed ranges read raw samples;
• wider ranges can read a matching rollup;
• an ineligible selector falls back to a finer rollup or raw samples;
• source timestamps are never assumed to have a fixed scrape interval.

The default rollup level design includes 60 s, 720 s, 7,200 s, and 86,400 s buckets, configurable at schema creation time.

Ingestion

Send OTLP metrics to POST /v1/metrics or Prometheus remote write to POST /api/v1/write. OTLP metric names and labels are translated using Prometheus-compatible conventions, including job, instance, and target_info synthesis.

Compatibility goal

Full PromQL compliance is a project requirement and is tested against upstream Prometheus parser and query corpora. The implementation combines ClickHouse pushdown with Rust-side evaluation where SQL lowering would alter PromQL behavior.