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.

Thanks for mentioning qryn! We are a non-corporate alternative and feature full ingestion compatibility with DataDog (including Cloudflare emitters, etc), Loki, Prometheus, Tempo, Elastic & others for both on-prem (https://qryn.dev) and Cloud (https://qryn.cloud) deployments, without the killer price tag.

Note: in qryn s3/r2 are as close to /dev/null as it gets!

Progress is happening! ~24.8% performance increase and much better results expected on the weak tests with the latest jemalloc patches by @auxten + a golang binding as alternative to the python one for those afraid of snakes! ;)

This comment is important :)

It's fast! For those interested, here are the project links:

- https://github.com/auxten/chdb - https://github.com/metrico/chdb-server

qryn and vector get along very well! We use it all the time for testing and developing qryn and qryn.cloud and most of our users love it! But since qryn supports Logs, Metrics and Telemetry at once, we're just as compatible with any Agent supporting Loki/LogQL, Influx protocol for metrics and logs, Elastic Bulk, Prometheus for metrics, opentelemetry for everything... and more coming!

Feel free to open an issue on our repository if you end up trying it and/or would like us to help out!

https://qryn.dev https://qryn.cloud

Thanks for the feedback! qryn developer here, and that's exactly our design goal: requiring no custom agents or clients in order to use our solution, through API emulation. There's a chance you could use qryn as a reader for data written by other clients, and that's exactly what we do with opentelemetry where we have a qryn-otel-collector allowing direct writes into ClickHouse at max speed, just like signoz, and reading through our Grafana compatible APIs using qryn.dev or qryn.cloud

Thank you for mentioning qryn! And yes, thanks to our growing community the rough edges should all be well rounded and we now support logs, metrics and telemetry formats with very decent results at a fraction of the complexity, without reinventing the wheel or adding new protocols and formats for people to adopt and learn. It's good if it just works right? And now with https://qryn.cloud we continue our mission towards a lightweight polyglot stack for core and edge observability - on top of the growing ClickHouse superpowers, as always!

Disclaimer: I work on qryn

Funny to read this since based on my testing so far DuckDB is not quite rockstable yet, requires preloading the httpfs module and setting 5 parameters each tun just to query a file off S3 (often very slowly, mostly because of the folder crawling/list logic?) with non standard SQL for extensions and segfaults frequently during testing if the remote server has any unexpected response (also not working too well with S3 clones). The WASM version differs in s3 settings, too but this is not well documented. If you really love opensource and with such a long career you should know there is no point in badmouthing other projects in order to achieve success, particularly from leadership positions. Just make DuckDB great and let happy users speak on your behalf. Nobody wants to be part of a toxic community this early in.

I do NOT work for ClickHouse, but I've been running super stable distributed CH clusters for years.

I couldn't agree more. clickhouse-local is great as a CLI tool as well as a relay for web driven functions, delivering all the clickhouse functionality and speed for ad-hoc tasks with local or remote storage on S3, Parquet files, etc.

Disclaimer: I do NOT work for ClickHouse :)

it would be nice to use ClickHouse as a Prometheus backend

Well... that's already possible and it works great! As you might know https://qryn.dev turns ClickHouse into a powerful Prometheus *remote_write* backend and the GO/cloud version supports full PromQL queries off ClickHouse transparently (the JS/Node version transpiles to LogQL instead) and from a performance point of view its well on par with Prometheus, Mimir and Victoriametrics in our internal benchmarks (including Clickhouse as part of the resource set) with millions of inserts/s and broad client compatibility. Same for Logs (LogQL) and Traces (Tempo)

Disclaimer: I work on qryn

Pt.2 is out https://blog.qryn.dev/wrapping-a-serverless-clickhouse-pt2