Skip to main content

​
Ingestion

Ingestion was measured with p8s-bench, a harness around VictoriaMetrics’ prometheus-benchmark tool. The load generator produced samples for 5,100 targets every 60 seconds, for a total of ~3.3M unique active series. On a single m5.xlarge node (4 vCPU, 16 GB RAM) with SlateDB’s WAL disabled, Timeseries sustained:
Soak chart showing ingestion holding at ~55k samples/sec over time

Sustained ingestion rate over the soak test on a single m5.xlarge node.

Disabling the WAL is acceptable for many timeseries workloads, particularly those paired with a durable upstream log like OpenData Buffer.

​
Query latency

Query latency depends mostly on how much data a query touches and whether that data is already in the SlateDB block cache. The chart below plots cold and warm query latency as a function of the number of series matched and scanned over a 6-hour time range.
Bar chart comparing cold and warm query latency across increasing series counts

Cold vs. warm query latency by number of series scanned over a 6-hour range.

Warm numbers are the ones that matter for day-to-day use: alerts and active dashboards keep their data warm, and once recent data is in the block cache, queries stop paying object-store round trips. On the benchmark r5d.xlarge node, roughly 8 GB of RAM plus ~140 GB of NVMe-backed disk cache keep several weeks of data warm (assuming 1–2 bytes per sample for Gorilla-compressed blocks). Cold reads pay the object-store round trip (10–100 ms).

​
Cost

The same workload (3.3M active series, 4.7B samples/day) costs roughly $560/month of compute:

​
Reproduce it