DuckDB Isn't Just Fast
csvbase.com
DuckDB Isn't Just Fast
1–10 of 40 posts
Re: DuckDB Isn't Just Fast
#2Really, is this what's getting praised? I mean specifically the first point: the whole "just paste the url into the DB" - thing, + inferring the column names. That looks like the laziest and shakiest basis, and if I ever saw that in production i d be both stunned and scared
Re: DuckDB Isn't Just Fast
#3Really, is this what's getting praised? I mean specifically the first point: the whole "just paste the url into the DB" - thing, + inferring the column names. That looks like the laziest and shakiest basis, and if I ever saw that in production i d be both stunned and scared
It is a really useful feature for ad hoc examination of datasets. Not every data-analysis is going into a massive, mission critical production build chain. Quite often you just want to look at the data in a REPL and IMO that sort of usage could bear to get a little easier
Re: DuckDB Isn't Just Fast
#4I know I'm repeating my self (it must be my third comment on HN about this topic), but this does not match my experience at all.
DuckDB will error-out with an out-of-memory exception in very simple DISTINCT ON / GROUP BY queries.
Even with a temporary file, an on-disk database and not keeping the initial order.
On any version of DuckDB.
Re: DuckDB Isn't Just Fast
#5I know I'm repeating my self (it must be my third comment on HN about this topic), but this does not match my experience at all. DuckDB will error-out with an out-of-memory exception in very simple DISTINCT ON / GROUP BY queries. Even with a temporary file, an on-disk database and not keeping the initial order. On any version of DuckDB.
Sounds like the very early versions of EF Core which did not translate C# GroupBy into SQL GROUP BY, but instead loaded the /entire/ data set into memory and did the aggregate there.
Re: DuckDB Isn't Just Fast
#6uhm why would you ever use this instead of sqlite
Re: DuckDB Isn't Just Fast
#7I know I'm repeating my self (it must be my third comment on HN about this topic), but this does not match my experience at all. DuckDB will error-out with an out-of-memory exception in very simple DISTINCT ON / GROUP BY queries. Even with a temporary file, an on-disk database and not keeping the initial order. On any version of DuckDB.
Sounds interesting. Is there a open issue for this? I found https://github.com/duckdb/duckdb/issues/8505 but it seems that that specific issue is closed.
Re: DuckDB Isn't Just Fast
#8I know I'm repeating my self (it must be my third comment on HN about this topic), but this does not match my experience at all. DuckDB will error-out with an out-of-memory exception in very simple DISTINCT ON / GROUP BY queries. Even with a temporary file, an on-disk database and not keeping the initial order. On any version of DuckDB.
Thanks for repeating yourself; this comment potentially influences my decision-making about DuckDB. Good to know about the negatives too.
At what data volumes does it start erroring out? Are these volumes larger than RAM? Is there a minimal example to reproduce it? Is this ticket related to your issue? https://github.com/duckdb/duckdb/issues/12480
Re: DuckDB Isn't Just Fast
#9DuckDB has great ergonomics for moving data between different databases and making copies for local analysis.
The one thing that differed in my experience with it from the author’s is how much of the Postgres sql dialect (and extensions) it supports. Attempting to run my Postgres analytics sql code in duckdb errors out on most json operations - to be fair, the DuckDB json functions have cleaner names than jsonb_path_query - also, DuckDB has no support for handling xml, so all xpath calls fail as well.
Re: DuckDB Isn't Just Fast
#10uhm why would you ever use this instead of sqlite
DuckDB is optimised for analytical tasks, whereas SQLite isn't.