disclaimer: I work at Oodle, posting my own perspective here.
Vijay and Kiran have both replied here in good faith. I like the fact that my bosses are nice, kind, and decent people.
I disagree with them about being nice to trolls.
All the past submissions from OP are for content hosted on a specific domain, which now redirects to another one: Surprise surprise! They sell "Telemetry Pipeline for AI-Era Data Volumes". So, a somewhat-competitor!?
OP, thanks for validation. When competitors write drive-by, unsubstantiated, undisclosed comments, that's good news!
We price per GB of ingested trace - $0.3/GB, goes lower as you scale.
Traditional APM spans are ~2KB - this would come to ~$0.6/million spans.
How we arrived at $10 is that we assumed each agent span is ~35KB. Which means 1M spans is ~35GB - which comes to ~$10. Agent spans are larger because they have large prompts.
If your LLM spans are smaller, the cost would be lower. For our customers we see this vary between 20-30KB, and we took a conservative 35KB number.
We store these files on S3 and directly read them in the query path using lambda functions. Parquet would work as a storage format for logs and traces, but not for metrics. At oodle we built the metrics engine first, so we designed a hybrid row/column format with a more S3 friendly indexing strategy - fewer lookups required to locate relevant chunks within the file. The hybrid row/column format was necessary to store multiple "samples" in the same row. This also allowed us to get compression ratios in the order of 600x.
When we extended the engine to logs and traces, we took the approach of tweaking the same file format so that we could re-use a majority of the engine we had already built.
"Oodle" to me will always be the compression library first and foremost, just like "pi" will always make me think first of the Raspberry Pi rather than the coding agent.
Perhaps someone should vibecode a product that allows AI developers to generate project names that don't come with confusing collision baggage.
Dang that’s expensive. We pay $0.75/M through a vendor
disclaimer: I work at Oodle, posting my own perspective here.
Vijay and Kiran have both replied here in good faith. I like the fact that my bosses are nice, kind, and decent people.
I disagree with them about being nice to trolls.
All the past submissions from OP are for content hosted on a specific domain, which now redirects to another one: Surprise surprise! They sell "Telemetry Pipeline for AI-Era Data Volumes". So, a somewhat-competitor!?
OP, thanks for validation. When competitors write drive-by, unsubstantiated, undisclosed comments, that's good news!
We price per GB of ingested trace - $0.3/GB, goes lower as you scale.
Traditional APM spans are ~2KB - this would come to ~$0.6/million spans.
How we arrived at $10 is that we assumed each agent span is ~35KB. Which means 1M spans is ~35GB - which comes to ~$10. Agent spans are larger because they have large prompts.
If your LLM spans are smaller, the cost would be lower. For our customers we see this vary between 20-30KB, and we took a conservative 35KB number.
Good to know. Could you share your vendor and capabilities and pricing page please?
Hi HN, Vijay here
Adding support for agent traces turned out to be a great learning experience - it pushed us to rethink and replace parts of our storage engine https://blog.oodle.ai/how-we-achieved-10-million-agent-spans...
Why a "parquet-like" format and not just parquet?
We store these files on S3 and directly read them in the query path using lambda functions. Parquet would work as a storage format for logs and traces, but not for metrics. At oodle we built the metrics engine first, so we designed a hybrid row/column format with a more S3 friendly indexing strategy - fewer lookups required to locate relevant chunks within the file. The hybrid row/column format was necessary to store multiple "samples" in the same row. This also allowed us to get compression ratios in the order of 600x.
When we extended the engine to logs and traces, we took the approach of tweaking the same file format so that we could re-use a majority of the engine we had already built.
The self-promotion spam will continue until the community improves.
love oodle’s speed and the best in class mcp. excited to try out agent tracing and evaluate the accumulated failure patterns
"Oodle" to me will always be the compression library first and foremost, just like "pi" will always make me think first of the Raspberry Pi rather than the coding agent.
Perhaps someone should vibecode a product that allows AI developers to generate project names that don't come with confusing collision baggage.