kirankgollu

Thanks varun! let us know what you think about surfacing agent failures automatically, happy to help with onboarding if that helps.

Good to know. Could you share your vendor and capabilities and pricing page please?

Our approach is that you need not worry about this. Oodle will be able to handle any scale including the ephemeral metrics.

Secondly, we only look at the unique time series in an hour when computing the billing. This should help us handle ephemeral metrics a lot better compared to many disk based data stores.

Finally, we do support high cardinality since the underlying datastore is columnar. Existing customers are sending on the order of few million cardinality per metric.

re: storing high cardinality metrics in disk vs in-memory index, vijay will comment shortly.

It's not a fair comparison. You can't compare the base tier pricing of Oodle offering with the high scale tier of victoria metrics. As you scale, volume benefits kick in just like the way they are for VM. It's a common wisdom that enterprise companies don't swipe credit cards beyond 50k/year. We request our customers to speak with us when they get to high scale tiers.

250k metrics - Oodle is 5x cheaper, < 5M metrics - Oodle 2-3x cheaper, beyond 5M - talk to us (our pricing will be competitive and will be better)

As suggested in earlier message, this pricing is only for single node. imo, this needs to be compared to cluster mode - any company with meaningful scale will need reliabilty and needs to run in cluster mode since you’d need your observability systems to be up and running when the rest of your systems are down.

Oodle is a fully managed, supports high availability, so was comparing against the cluster mode of victoria metrics cloud offering.

RE: Victoria Metrics Pricing: Pls see https://victoriametrics.com/products/cloud/. The pricing that you are referring doesn't seem public, looks like you've to sign up to see that pricing. $190/month is a single node pricing. For any real use cases, you need HA and victoria metrics enterprise pricing for a cluster starts at $1300/month for 250k metrics. This translates to $5.2 per 1k metrics (5x more expensive than Oodle). For a real scale about ~2.5M or ~5M time series / hour, Oodle is around half the cost of victoria metrics.

RE: Pricing dimensions, we've simplified our pricing by indexing on a single dimension. We don't require our customers to choose machine type, RAM, CPU etc. There are other limits but for the most part, they don't matter so much in our pricing.

RE: Pricing tiers, anything more than $30-50k/year (>5M time series / hour), companies usually to talk with someone for volume discounts rather than go with online pricing.

your comment said "no magic" and the links points to "#magic-behind-oodle". May be I misread your comment or you didn't mean that.

Not a fan of bad mouthing other offerings. As @iampims is saying, alerts is a big missing piece. Clickhouse is also a general purpose database for many use cases including analytics, financial servers, ML& Gen AI, fraud, and observability.

It'd be nice to post a disclaimer if you are working on a competing offering before you post a comment. (for the benefit of everyone)

Thank you for the feedback. we will keep an eye out for more inputs from our users on this topic.

We believe there are clear benefits of open source. In fact, we believe in it so much that we made our product OSS compatible from Day 1. (btw, not every observability product is OSS compatible).

We also understand not everyone's evaluation criteria is the same. Upon speaking with number of our early users, we repeatedly found that what really matters is "is the product reliable, cost-effective?", "is the product easy to use and open source compatible?", "is the product easy to migrate in/out?". So, we tried to address those head on. We also heard some open source solutions are indeed unreliable especially at scale e.g. Prometheus has scaling challenges beyond 2M+ active time series / hour and it is not horizontally scalable. People tend to over-provision CPU/Memory, despite that queries time out at any meaningful scale high cardinality queries (this is a well understood problem).

Ability to inspect code, do patches themselves may be an evaluation criteria for some users, we found that it was not the major evaluation criteria among our users. I've led multiple evaluations at Rubrik (open source + non-open source), ability to patch software was not the most important criteria - reliability, operational overhead, cost, ease of use, and ability to switch in/out were may more important.

That's fair.

We actually started with "reduce your costs by 3-10x with infinite scalability" without talking about storing in s3 and serverless (along the lines of your thinking - only talk about benefits + what you do). But our users, engineers by their very nature, were skeptical about how Oodle works, so we ended up settling on a combination of why, what and how. This resonated better with our early customers and prospects.

Oodle is a fully managed offering. Curious why you think Victoria Metrics Cloud is still cheaper. https://victoriametrics.com/products/cloud/

This translates to about $5.2 per 1k metrics, Oodle is $1 per 1k metrics!

Am I missing something?

Thanks for your inputs, we will followup.

thanks for the pointer on logo - we are fixing it later today.

Edit: fixed now.

The actual mileage may vary here - we found this to be true for our early customers. Our pricing is simple, and transparent - https://oodle.ai/pricing. Based on our conversations, we consistently hear this is very cost-efficient. Pls let us know if you feel otherwise - but one can can easily input the #active time series / hour to get an estimate from Oodle.

We don’t have plan to open source at this time. Many observability solutions are closed source. Could you please describe why you would require this to be open source vs open source compatible?

We think Oodle combines the benefits of open source (compatibility, no lock-in) with the operational simplicity, reliability of commercial vendors. Some products might give a false illusion of no-lock in just because it's open source, it wouldn’t mean you don't have lock-ins. We believe what really matters is "Open Source Compatible" - i.e. how easy it is to get in? How easy is it to switch out? (to a de-facto open source standard like Prometheus/Grafana should you need to disconnect ties with the vendor). Security and compliance is the other big part - we are working on adding compliance like SOC2, CCPA etc.

we leverage serverless and s3 based architecture for much lower costs. However, it's applies for any application, not just for serverless applications.

Thanks for the kind words - we will be posting a feature comparison matrix in the upcoming weeks on our website.

ClickHouse is great for logs and traces, however, for metrics, it is still in the early phase. ClickHouse is also a general purpose, real time analytics database. See clickhouse.com. Whereas Oodle is specifically built for end-to-end metrics observability.

Thanks for the report - we just deployed fix for the same.

No lock-in means it’s 100% open source (PromQL) compatible. You can swap out vendors or move to self-hosted open source solutions should you need to move away from Oodle. When you migrate out, you get to export all your data, dashboards and alerts. you don't need to make any code changes.

We support bringing your own bucket (BYOB) for large enterprise customers however, you cannot bring your own compute at this time. Our thoughts are along the lines of how Snowflake approached the problem - everything fully managed to keep the operational overhead minimal. https://jack-vanlightly.com/blog/2023/9/25/on-the-future-of-...

Our P99 query latency is under 3 seconds, we have tested up to 100M unique time series / hour and the architecture can scale up to billion time series / hour. To get a feel of the performance at high scale, give us a try at https://play.oodle.ai

With our custom columnar format and indexes, we are able to filter relevant data files where high cardinality column is present. This helps us to keep the queries faster for high cardinality labels as well, thus, allowing us to quickly drill down on specific pod_id/cluster_id/customer_id kind of labels.

It’s indeed Grafana. We’ve been maintaing a public fork of Grafana.

Point taken. Thanks for the feedback. Our reasoning is that we’d like the name to be short and memorable. And a bunch of observability companies have observe keyword overloaded all over the place, we wanted our name to stand out. Oodle = Optimized Observability Data Lake.

This architecture diagram (https://oodle.ai/product#magicbehindoodle) goes into more detail into where we leverage Serverless. For ingestion, we still use dedicated compute, but for queries, we leverage serverless.

yes, it's only fully managed at this time. However, oodle is very cost-efficient, it's cheaper than your self-hosted infra costs. https://oodle.ai/usecases/self-hosted

Thanks for the heads up. we did check on IP/trademarks just to be sure to avoid violations.

Rubrik| Senior Software Engineer | Full-time | https://www.rubrik.com/en/company/careers/departments/job.22...

We are looking for software engineers to build a highly-scalable Polaris Cloud Data Management Platform that enables product team engineers to ship/operate features with high quality and velocity. Projects include scaling distributed database by sharding MySQL instances, distributed workflow engine built on top of kubernetes, and scalability and stabilization of tier-0 services.

Join us to work on GCP/AWS, Kubernetes, Golang, gRPC/GraphQL and more.

Thanks Shafi for feedback! Although it may not be the highest priority, we'll will look into adding theme support at some point.

@chadboyda: Good point, per-partition throughput reduces as the #partitions increases but if your load is uniform, it wouldn't impact your overall throughput. Neptune does take this into consideration, although we can't change the inherent DynamoDB behavior. We talk about how to address this problem proactively in our best practices. Our recommendation: create table with 12-month peak throughput and then immediately bring it down to what you want right now. If the table is already created, bump up the throughput to the 12-month peak just once and then bring it down to what you want right now. In either case, this will ensure DynamoDB doesn't change partitions internally when you scale up and scale down within in 12-month peak range. But if you range goes beyond the peak, you'd still run into the problem that you'd described. We've seen in many case, people can predict the highest peak with reasonably high confidence. (think database world where they'd always known this in the past for many years).

Refer to our first best practice point for more details: http://blog.neptune.io/dos-and-donts-of-dynamodb-autoscaling...