I currently manage 50m active series and it’s brain dead easy using Mimir (which can also easily do 100-200m).

That being said, perhaps this Parseable project is much more efficient (RAM) in storing that 1b samples compared to Mimir (RAM). Once we add in object stores which cheapen the storage cost by orders of magnitude (by going from memory to disk), the comparison is even weaker. Mimir and Cortex/Thanos are quite happy to pull cold data from S3.

So I too expected to see “billions” as well.. hmm.

We haven't yet tried pushing it to the scale of billions yet. The max that we've gone to is 150-180 million.

Fair question. 100M isn't a ceiling, it's what we have seen in that deployment. We have not run a billion series test yet.

The reason we think it scales differently - labels are just columns in Parquet, so there is no per series index that grows with cardinality. In that deployment one label alone has ~2.5M distinct values among 500+ labels, which would be painful for an index based TSDB but here is just a high cardinality column. What drives cost for us is ingestion rate (data points/s) and how much data a query has to scan for a particular time range not series count. Ingest scales horizontally by adding ingestors, and queries prune by time partition and column stats.

A billion series benchmark is on our list, and we'll publish the numbers when we run it.

scrape interval is 15s and sustained ingestion we have seen is ~3M samples/sec that is ~300 TB/day of raw ingest payload, when stored on object store as parquet, the data gets compressed to 99% which makes it 3 TB/day. The 100M figure is total unique series seen over time. For a sense of per metric cardinality, one metric that has the highest cardinality label (2.5 M distinct values) shows ~6M active series per hour.

Sizing for this kind of deployment was a lot of fun! We went ahead with- 5x Ingestors, each with 64 vcpu 128 GB

5x Queriers, each with 64 vcpu 192 GB

The current utilization sits comfortably at 10-15 vcpu and 20-30 GB memory for the ingestors 20-40 vcpu and 40-60 GB memory for the queriers

Ample of headroom for transient spikes and planned near-future growth