connector-x VS duckdb

This was originally a blocker, however, we managed to set up a multi-stage Docker build to build from source. Here is the Github issue where we, along with community members, managed to solve it.

There's packages like connector-x and polars that do a lot of what you're mentioning out of the box. I used these two to massively speed up an SQLalchemy + Pandas based ETL in the past as well.

Thanks for sharing connector-x, I will also start to use it. I wonder if there are a list of tools like that. I know Ruff, Polars, pydantic-core.

I was trying https://github.com/sfu-db/connector-x and hacking around with this https://github.com/spitz-dan-l/postgres-binary-parser but it turned out that a COPY to csv using asyncpg and then converting to parquet was the fastest.

if you store the OHLC data in a relational database, use connector-x to load the data into pandas dataframe

For SQL reading I'd really recommend connector-x, they do a great job preventing unneeded serialization and don't have to go through python.

Indeed, currently we do not support persistent connections among different queries. We target more on the bulk loading scenario where the bottleneck is caused by the data size and the connection construction overhead is negligible. However, one possible solution to the problem is to expose our connection pool object that we use inside Rust to users, so the next call could reuse the same pool. We do not plan for this yet, but happy to see whether this is a common need! Feel free to open an issue in our github repo: https://github.com/sfu-db/connector-x

Feel free to ask any questions here or open an issue in our github repo: https://github.com/sfu-db/connector-x . You can also join our discord community: https://discord.com/invite/xwbkFNk and ask question under connector channel!

I'm not sure if the fix is reassuring or not: https://github.com/duckdb/duckdb/pull/9411/files

It's an interesting question!

The problem is that the data is spread everywhere - no choice about that. So with that in mind, how do you query that data? Today, the idea is that you HAVE to put it into a central location. With tools like Bacalhau[1] and DuckDB [2], you no longer have to - a single query can be sharded amongst all your data - EFFECTIVELY giving you a lot of what you want from a data lake.

It's not a replacement, but if you can do a few of these items WITHOUT moving the data, you will be able to see really significant cost and time savings.

[1] https://github.com/bacalhau-project/bacalhau

[2] https://github.com/duckdb/duckdb

[4] Switch to Push-Based Execution Model by Mytherin · Pull Request #2393 · duckdb/duckdb (github.com)

it depends on your query obviously.

In general, I did very deep benchmarking of pg, clickhouse and duckdb, and I sure didn't make stupid mistakes like this: https://news.ycombinator.com/item?id=36990831

My dataset has 50B rows and 2tb of data, and I think columnar dbs are very overhiped and I chose pg because:

- pg performance is acceptable, maybe 2-3x times slower than clickhouse and duckdb on some queries if pg is configured correctly and run on compressed storage

- clickhouse and duckdb start falling apart very fast because they specialized on very narrow type of queries: https://github.com/ClickHouse/ClickHouse/issues/47520 https://github.com/ClickHouse/ClickHouse/issues/47521 https://github.com/duckdb/duckdb/discussions/6696

This action installs duckdb with the version provided in input.

Duckdb: https://github.com/duckdb/duckdb - seems pretty popular, been keeping an eye on this for close to a year now.

The Parquet-Go library is very complex, not yet success to use it. So I ask whether DuckDB can provide API https://github.com/duckdb/duckdb/issues/7776