[brancz]

Hey HN! Myself and several members of the Polar Signals team have been long time Observability ecosystem maintainers of projects such as Prometheus, Thanos, Cortex, Kubernetes and many more. In 2018 we read the "Google-Wide Profiling" paper and immediately realized we have to treat profiling just like any other Observability data, by systematically and comprehensively collecting it for our entire infrastructure and applications and store that throughout time.

At the same time eBPF was on the rise and it was a match made in heaven, we can provide an incredible user experience without requiring any code changes, and all our users need to do is deploy an agent (a single command to run against a Kubernetes cluster), and we can profile just about any popular language (and those that we can't profile yet we have on the roadmap). Not only does eBPF get us an incredible user experience, it also allows us to collect this data at never-before-seen low overhead (<1%) since we can grab exactly the data we need and nothing more.

In addition to that we built a custom columnar database to back this product to allow a Prometheus-style label-based query language to work on this very high cardinality data.

In a world where the economics of Moore's Law have already stagnated, everyone is going to have to learn to build more efficient software, and the root of all evil performance optimizations are those that are not based on measurements.

We're going to be hanging out in the comments all day, so please feel free to ask us any questions you might have, as well as any feedback you have for us!

[boxed]

The pricing tiers seem a bit rough for small shops. One to 44 CPUs are the same 50 dollars per month right? I work a very small shop with just me as the developer and just one server. I'd really like something smaller.

[brancz]

Pricing is never final, so that feedback is valuable, thank you! If you want to schedule a chat I'd love to learn more about your use case and happy to figure out what works for you!

https://calendly.com/frederic-branczyk/getting-to-know-polar...

[mdaniel]

> In addition to that we built a custom columnar database

I did some digging in your blog history and it seems that is referencing https://www.polarsignals.com/blog/posts/2022/07/22/frostdb-i... and digging into the "but why?" section <https://github.com/polarsignals/frostdb#why-you-should-use-f...> seems to imply you favored the embedded feature over having something standalone, but I would enjoy hearing (or reading a blog post!) about why you felt it was a better use of your engineering to make your own columar DB versus using one of the existing columanr dbs that I have seen referenced a ton in other Show HN announcements around both logging and metrics services

[brancz]

Great question!

The big one that existing columnar databases can’t do (or not well), is the ability to search and aggregate on user defined dimensions (think prometheus-style labels). Influx 3.0 is the only other columnar database that is (now) available that was engineered specifically to be able to do this. The good folks at honeycomb came to the same conclusion that this type of columnar database (wide column) is necessary to build Observability with exceptional user experience. Plus we now own our future and can do any kind of optimization while other companies (and I’ve spoken to them) constantly fear ClickHouse relicensing or otherwise destroying their business.

//edit: we call this feature dynamic columns: https://github.com/polarsignals/frostdb#dynamic-columns

[buro9]

Congratulations on the launch, it's been great watching your journey so far.

[brancz]

Thank you for the kind words! Try the product and let us know what you think! :)