Re:Show HN: Parseable, an open observability datalake, handl...
by goldeneye13_ on Tuesday October 06, 2026 @11:35AM
(#49980078)
This looks super interesting. Question about the scale, I thought Thanos and some other Prometheus variants can handle about 100 million active time series. I would have expected your solution to scale to billions. Have you not pushed it past 100 million or am I maybe missing something.
Re:Show HN: Parseable, an open observability datalake, handl...
by parmesant on Tuesday October 06, 2026 @12:05PM
(#49980507)
We haven't yet tried pushing it to the scale of billions yet. The max that we've gone to is 150-180 million.
[dead]
Re:Show HN: Parseable, an open observability datalake, handl...
by kyxsc on Tuesday October 06, 2026 @05:53PM
(#49984665)
Definitely publish it! I’ll be following closely! 100M seems a bit too low to turn heads, but cool project nevertheless. Always exciting to see open source observability tools pop up!
Re:Show HN: Parseable, an open observability datalake, handl...
by kyxsc on Tuesday October 06, 2026 @05:51PM
(#49984631)
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.
Re:Show HN: Parseable, an open observability datalake, handl...
by skrtskrt on Wednesday October 07, 2026 @11:46AM
(#49994483)
Yeah Mimir cleared a billion series years ago prior to several recent re-architectures that make it faster and more efficient to run.
Re:Show HN: Parseable, an open observability datalake, handl...
by msandford on Tuesday October 06, 2026 @10:29AM
(#49979082)
100M active time series is good information, but what's the data rate for each time series it can handle? One update per minute or 10 per second? There's a factor of 600 difference there. Neither is obviously insanely the wrong update rate.
Re:Show HN: Parseable, an open observability datalake, handl...
by nikhil4usinha on Tuesday October 06, 2026 @11:35AM
(#49980070)
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.
Re:Show HN: Parseable, an open observability datalake, handl...
by gustavohoa on Tuesday October 06, 2026 @12:55PM
(#49981119)
How does the 100M active series deployment looks like? How many ingestors are there? What's each instance size? How big is the querier so that it can query across a metric with millions of active series?
Re:Show HN: Parseable, an open observability datalake, handl...
by parmesant on Tuesday October 06, 2026 @02:05PM
(#49981949)
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
Re:Show HN: Parseable, an open observability datalake, handl...
by codegeek on Tuesday October 06, 2026 @05:21PM
(#49984328)
Your pricing page calculator is a bit strange. The minimum daily is set to 1 TB which is too high. Are you not interested in working with companies that have lesser ingestion ?
Re:Show HN: Parseable, an open observability datalake, handl...
by yashdotrv on Wednesday October 07, 2026 @02:11AM
(#49988938)
Oh I see, what you say! ...but that’s intentional... we start the calculator at 1 TB/day because beyond this scale it's usually where observability pricing starts to hurt and ROI discussions kicks in. So, the point we’re trying to show is that, even at 1 TB/day, Parseable will still cost you lesser than others, and easier to operate too. Also the best part is that you will have the complete ownership of your data.
Re:Show HN: Parseable, an open observability datalake, handl...
by jiggawatts on Tuesday October 06, 2026 @05:52PM
(#49984642)
> S3-compatible object storage
Azure doesn't exist.
This is Yash, founding team at Parseable (https://github.com/parseablehq).
We've built an open source observability data lake using Rust, that handles high-cardinality data at around 100M time series in production (https://www.parseable.com/blog/how-parseable-handles-100-mil...)
Our architecture is built around columnar design, and we use Apache Arrow for in-memory columnar processing and Apache Parquet for durable columnar storage on S3-compatible object storage. In Parseable, every labels stay as columns in the data instead of becoming a large long-lived per-series index like many TSDBs.
Also, one thing we’ve been thinking about a lot is how observability changes as agents become part of day-to-day engineering workflows. They're not just another service, they produce traces, tool calls, prompts, intermediate decisions, errors, costs, and sometimes sensitive business context.
Observing them matters just as much as observing any other system. But it is equally important to decide where that telemetry data should reside. Our view is that teams should be able to keep these observability data close to them: in their own object storage, under their own retention, access, and compliance controls.