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
Unless you have heavy experience hosting and tuning prometheus, its not easy to be that cost efficient. It has a tendency to OOM crash on heavy queries if enough memory isnt provided, and provisioning huge memory for occasional queries becomes expensive quickly. Not to mention backups and replicas.
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.
any plans to open source? I feel very comfortable using neon.tech (separates compute from storage for postgres) b/c they open source their stack but it would be hard for me to adopt something like oodle without an open source version.
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.
The primary benefit of FOSS is the ability to inspect and patch the software yourself. Another important benefit for any large FOSS project is knowing it’s been heavily reviewed.
Protocol compatibility is a baseline requirement for a drop-in replacement. Without that, your product would need to be like 10x cheaper than Prometheus for anyone to consider devoting engineering resources to switching to it.
Existing FOSS solutions are reliable and inexpensive enough, not even considering the effort and unknowns involved with swapping out a major component of the observatory stack. Between that, your distorted view of open source, and your focus on checkbox compliance, I’m unlikely to ever consider trying your software. I wish you luck though, and I hope you learn more about the value of FOSS.
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.