01
Read-path first
Schema and planner decisions begin with the dashboard, search and drilldown queries they must serve.
In active development
One read path.
One read path.
Every signal.
Ingest with OpenTelemetry. Query with PromQL, LogQL and TraceQL. Let PulsusDB turn them into ClickHouse-native SQL.
OPEN TELEMETRY
logs12.8k/s
metrics48.2k/s
traces6.4k/s
profiles1.7k/s
PulsusDB compile + plan
CLICKHOUSE SQL
SELECT service, count() FROM log_samples PREWHERE ts BETWEEN … GROUP BY service query completed42 ms
SPEAKS YOUR STACK
OpenTelemetry PromQL LogQL TraceQL ClickHouse
Built from the query backwards
Your telemetry is not one shape of data.
Logs, metrics, traces and profiles behave differently. PulsusDB gives each signal a purpose-built ClickHouse schema, ordering strategy and read path—then presents the APIs your tools already understand.
Read the architecture ↗02
Shard-aware by design
Resolve labels without broadcasting every lookup across every shard.
03
Spend fewer reads
Use time filters, ClickHouse indexes and rollups where the query can stay exact.
04
See the plan
X-Pulsus-Explain: 1 exposes generated SQL, routing and planner stages when you need to know what the query actually did.
Keep the languages. Change the engine.
No new query dialect to learn.
Write the queries your team already knows. PulsusDB parses, plans and compiles them for ClickHouse.
logs.queryLogQL
{service_name="checkout"} |= "timeout"Resolve labels first. Use text indexes to avoid brute-force scans.
generated.sqlCLICKHOUSE
SELECT ts, labels, body
FROM log_samples
PREWHERE ts BETWEEN $start AND $end
AND fingerprint IN (…)
WHERE body LIKE '%timeout%'
ORDER BY ts DESC LIMIT 100
primary key pruned4,096 rows read
metrics.queryPromQL
sum by (service) (rate(http_requests_total[5m]))Keep the Prometheus API. Push safe work into ClickHouse, evaluate the rest faithfully.
generated.sqlCLICKHOUSE
SELECT service, toStartOfInterval(ts, 60)
AS bucket, sum(value) AS samples
FROM metric_samples
PREWHERE metric_name = $metric
AND ts BETWEEN $start AND $end
GROUP BY service, bucket
primary key pruned4,096 rows read
traces.queryTraceQL
{ resource.service.name = "api" && duration > 1s }Search traces by the attributes engineers actually use, not only by trace ID.
generated.sqlCLICKHOUSE
SELECT trace_id, min(start_ts), max(end_ts)
FROM trace_spans
PREWHERE service = $service
AND start_ts BETWEEN $start AND $end
WHERE duration_ns > 1000000000
GROUP BY trace_id ORDER BY min(start_ts) DESC
primary key pruned4,096 rows read
Prometheus HTTP API Product-neutral query APIs Optional compatibility endpoints WebSocket live tail
Simple where it should be
Stateless in the middle.
ClickHouse underneath.
Run everything in one process, or scale ingestion and query independently. Every durable byte remains in ClickHouse.
SHIP
OTel CollectorOTLP + remote write
logsmetricstracesprofiles
TRANSLATE
PulsusDBsingle Rust binary
STATELESS writerparse + batch
readerquery + plan
rulerevaluate + write back
modeallwriterreader
STORE
ClickHousedurable state + distributed compute
Start small with all mode and a single ClickHouse node.
Split writer and reader modes as the workload grows.
Restart and load-balance PulsusDB freely; caches are rebuildable.
Compatible by choice
Bring the dashboards.
Leave the lock-in.
PulsusDB’s product-neutral APIs are always on. Enable compatibility endpoints when you want existing datasources and dashboards to connect without changing their language.
PULSUS_COMPAT_ENDPOINTS=true Open source. Built in the open.
Follow the work,
shape the platform.
PulsusDB is an AGPLv3 Digitalis product under active development. The architecture, compatibility work and implementation decisions are documented in public.
$ git clone digitalis-io/pulsusdb
Cloning into 'pulsusdb'...
$ cd pulsusdb
$