I'd be curious to hear how this compares to
and
https://github.com/highlight/highlight
(There are some interesting comparisons/comments vs signoiz in sibling threads).
and
https://github.com/highlight/highlight
(There are some interesting comparisons/comments vs signoiz in sibling threads).
For qryn the vision remains "abstracting" our two-way polyglot Observability APIs transparently on top of multiple modern data backends (InfluxDB IOx/Flight is right next!) and being able to operate on both edge (light js) and core (fast go/rust) and provide users more choice and control as of how they can spend resources to store and leverage the data they collect in as many ways as possible, while transparently using the protocols, tools, agents and formats they already love and trust.
Inserting lots of Observability data really fast is relatively easy nowadays but reading the same data back from multiple APIs supporting multiple vendors formats is where qryn comes in strong without requiring new tools or plugins. We love to think of qryn as one of the many good vendor-locksmith tools for observability integrators out there who want more of out their data.
If anyone's curious you can try and benchmark qryn for free at https://qryn.cloud
We think that managing clickhouse is extra effort. Direct access to object storage is vital for cost reduction which is somewhat difficult in clickhouse. Small resource footprint is extremely valuable to many too. Simplicity of deployment is key to get started and many will use a product simply because they can. I know, I have used products that simply ran, and for no other reason.
Our best wishes to all the 3 teams.