qxip

qryn developer here, thanks for the mention and for the kind words! hope we'll get another shot in the future!

That's right! Under the hood we're doing the same thing when a UDF function is created so its still language agnostic, but for python it offers much nicer and needed wrapper - designed for actual users and not for showcase. If this will translate just as well to other chdb bindings (go, rust, node, bun, etc) allowing them to attach native functions, UDF might become a major force for chdb adoption.

Awesome! Ping me and I'll be happy to assist with the docs integrations - for now I've added a link to your guide

Best chdb example and tutorial I've seen so far! I love how easy codapi makes this, well done AntonZ!

note: I'm one of the chdb maintainers

I ran the same queries and got similar results but the bandwidth utilization I measured was significantly different. On the same fly.io instance with 1vCPU/256MB both queries completed successfully but ClickHouse/chdb reached 10MB/s (max) and logically completed the count faster, while DuckDB only peaked at around 2.5MB/s.

This might be due to the tiny resources but I like rock bottom measurements. Did anyone else notice a similar bandwidth utilization gap?

Great work Dennis!

Here you go: https://github.com/chdb-io/chdb/blob/92024bde839a8e9a42f68ae...

You can find a basic REPL/CLI for chdb here: https://github.com/chdb-io/chdb-cli

no chdb wasm versions are planned or even possible at the moment. This ClickHouse thread is still relevant: https://github.com/ClickHouse/ClickHouse/pull/37871

Disclaimer: I am a chdb maintainer! duckdb is currently thinner and has lots of active contributors and mature integrations, while chdb is still in its early stages BUT if you already love ClickHouse (like we do) chdb is a great choice as it inherits all the ClickHouse stability, performance and more importantly, all the 70+ supported formats for the embedded use case without any of the server/client requirements, making it perfect for fast in-process and serverless OLAP executions.

Note chdb is based on ClickHouse codebase but completely community powered so there's no feud with DuckDB (I'm a quackhead, too!) which actually offers lots of great inspiration and many integration opportunities with ClickHouse/chdb for combined compute and processing of datasets. I personally love both and use them together all the time in my colab "OLAPps"

Different beasts, but if by any chance you love ClickHouse already and just want to run OLAP queries in-process, there's chdb: https://github.com/chdb-io/chdb

Nothing to watch out against. You're referring to a simple dockerfile for convenience of testing and displaying configuration options, while neither Grafana or Minio are part of IOx or the community builds.

chdb maintainer here, thanks for sharing! Our brand new documentation website just got published: https://chdb-io.github.io

chDB keeps growing and now supports X64/ARM64 platforms, persistent query sessions to disk, UDF functions and more binding targets! We're looking for more OSS friends, maintainers, contributors and developers to join the project! Up for grabs areas include:

- C++ core - Go binding - Rust binding - Node binding - CLI and Toolsets - {your ideas}

If you love ClickHouse and want to take it with your anywhere, come build chDB with us: https://discord.gg/Njw5YXSPPc

For anyone interested, Self-Hosted InfluxDB3.0 IOx builds & containers are available here: https://github.com/metrico/iox-community

That's inaccurare: qryn does not require SQL at all . It offers LogQL, PromQL, Tempo and other customizable APIs natively by design without requiring the user to know/learn anything.

About the easier aspect that's true - qryn is designed to be an "overlay" on top of various backends such as ClickHouse and IOx (pros and cons for each up to the user) and to provide full granular data control to the underlying set (compliance, gdpr, etc) rather than an all-in-one solution with its own proprietary formats.

I'm looking forward to learning more about VictoriaLogs! You guys always come up with elegant solutions and I'm sure this will be no exception.

qryn developer here, thanks for the mention! We will be watching and following the evolution of this project as well as the established masters such as VictoriaMetrics with much admiration and curiosity. It's a busy space!

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

Not a clone, but surely sharing the potential, and an attempt at a viable in-process OLAP alternative for ClickHouse fans and enthusiasts.