influxdb_iox VS arrow2

Watch out for the AGPL minio <https://github.com/metrico/iox-community/blob/155a14bb5e8e32...> the almost certainly AGPL grafana <https://github.com/grafana/grafana/blob/v10.1.1/LICENSE> and always eye anyone who uses :latest images with healthy suspicion

That said, influx_iox itself appears to be Apache 2 (and/or MIT?) https://github.com/influxdata/influxdb_iox/blob/main/LICENSE...

have you looked at https://github.com/influxdata/influxdb_iox ? that's where the development for the new version is done.

As I understand, InfluxDB 3 is just a re-branding of InfluxDB IOx. Then its' performance can be not very good comparing to Prometheus-like systems.

InfluxDB iox

Don't know how much is open or closed, but they were doing some development in the open: https://github.com/influxdata/influxdb_iox

Just want to say congratulations to the team!

2 years and 9,500+ commits is a hell of a feat.

https://github.com/influxdata/influxdb_iox

Already is: https://github.com/influxdata/influxdb_iox Just still a work in progress.

It looks like this crate is the workaround for that. But there's a PR on SQLX opened a couple days ago that will fix the issue.

You should check out polars, datafusion, influxdb iox and databend, all written in native Rust and powered by the Apache Arrow format. Polars in particular is pretty dam fast and has bindings for Python.

One of the interesting components of Polars that I've been watching is the use of the Apache Arrow memory format, which is a standard layout for data in memory that enables processing (querying, iterating, calculating, etc) in a language agnostic way, in particular without having to copy/convert it into the local object format first. This enables cross-language data access by mmaping or transferring a single buffer, with zero [de]serialization overhead.

For some history, there's has been a bit of contention between the official arrow-rs implementation and the arrow2 implementation created by the polars team which includes some extra features that they find important. I think the current status is that everyone agrees that having two crates that implement the same standard is not ideal, and they are working to port any necessary features to the arrow-rs crate and plan on eventually switching to it and deprecating arrow2. But that's not easy.

https://github.com/apache/arrow-rs/issues/1176

https://github.com/jorgecarleitao/arrow2/pull/1476

https://github.com/jorgecarleitao/arrow2 https://github.com/apache/arrow-datafusion https://github.com/apache/arrow-ballista https://github.com/pola-rs/polars https://github.com/duckdb/duckdb

Currently datafusion and polars aren't directly operable iirc because they use different underlying arrows implementations, but there seems to be work being done on that here https://github.com/jorgecarleitao/arrow2/issues/1429

[arrow2](https://github.com/jorgecarleitao/arrow2) and [parquet2](https://github.com/jorgecarleitao/parquet2) are great foundational libraries for and DataFrame libs in Rust.

[1] https://github.com/jorgecarleitao/arrow2

In lockstep with arrow2's 0.13 release, we have published polars 0.23.0.

This is so freaking life-saving! - we have been using StreamingIterator and FallibleStreamingIterator in libraries (arrow2 and parquet2) and the existing landscape is quite confusing for new users!

arrow2 has support for mssql via ODBC (which microsoft has first class support to). Here are the integration tests we have (both read and write) against mssql specifically.