Kiran and Vijay here.
We built Oodle after seeing teams forced to choose between low cost, great experience, zero ops, and no lock-in. Even with premium tools, debugging still meant switching between Grafana for metrics, OpenSearch for logs, and Jaeger or Tempo for traces - copying timestamps, losing context, and burning time during incidents.
So we decided to rethink observability from first principles - in both architecture and experience.
Architecturally, we borrowed ideas from Snowflake: separated storage and compute so each can scale independently. All telemetry - metrics, logs, and traces - is stored on S3 in a custom columnar format, while serverless compute scales on demand. The result is 3–5× lower cost, massive scale, and zero operational overhead, with full compatibility for Grafana dashboards, PromQL, and OpenSearch queries.
On the experience side, Oodle unifies everything you already use. It works with your existing Grafana and OpenSearch setup, but when an alert fires, Oodle automatically correlates metrics, logs, and traces in one view - showing the latency spike, the related logs, and the exact service that caused it.
It’s already in production across SaaS, fintech, and healthcare companies processing 10 TB+ logs/day and 50 M+ time-series/day.
We’ve both spent years building large-scale data systems. Vijay worked on Rubrik’s petabyte-scale file system on object storage, and I helped build AWS S3 and DynamoDB before leading Rubrik’s cloud platform. Oodle applies the same design principles to observability.
You can try a live OpenTelemetry demo in < 5 minutes (no signup needed): https://play.oodle.ai/settings?isUnifiedExperienceTourModalO...
or watch a short product walkthrough here: https://www.youtube.com/watch?v=wdYWDG3dRkU
Would love feedback - what’s your biggest observability pain today: cost, debuggability, or lock-in?