zsv VS DuckDB

I wrapped zsv, a SIMD-accelerated CSV parser written in C, into a Ruby gem. SIMD means it uses special CPU instructions to process multiple bytes at once - the same tech that makes video encoding and game physics fast.

Haven't yet seen any of these beat https://github.com/liquidaty/zsv when real-world constraints are applied (e.g. we no longer assume that line ends are always \n, or that there are no dbl-quote chars, embedded commas/newlines/dbl-quotes). And maybe under the artificial conditions as well.

I cannot imagine any way it is worth anyone's time to follow this article's suggestion vs just using something like zsv (https://github.com/liquidaty/zsv, which I'm an author of) or xsv (https://github.com/BurntSushi/xsv/edit/master/README.md) and then spending that time saved on "real" work

If it could be tabular in nature, maybe convert to sqlite3 so you can make use of indexing, or CSV to make use of high-performance tools like xsv or zsv (the latter of which I'm an author).

https://github.com/BurntSushi/xsv

https://github.com/liquidaty/zsv/blob/main/docs/csv_json_sql...

Parsing CSV doesn't have to be slow if you use something like xsv or zsv (https://github.com/liquidaty/zsv) (disclaimer: I'm an author). The speed of CSV parsers is fast enough that unless you are doing something ultra-trivial such as "count rows", your bottleneck will be elsewhere.

The benefits of CSV are:

- human readable

- does not need to be typed (sometimes, data in the raw such as date-formatted data is not amenable to typing without introducing a pre-processing layer that gets you further from the original data)

- accessible to anyone: you don't need to be a data person to dbl-click and open in Excel or similar

The main drawback is that if your data is already typed, CSV does not communicate what the type is. You can alleviate this through various approaches such as is described at https://github.com/liquidaty/zsv/blob/main/docs/csv_json_sql..., though I wouldn't disagree that if you can be assured that your starting data conforms to non-text data types, there are probably better formats than CSV.

The main benefit of Arrow, IMHO, is less as a format for transmitting / communicating but rather as a format for data at rest, that would benefit from having higher performance column-based read and compression

I wanted so much to use csvkit and all the features it had, but its horrendous performance made it unscalable and therefore the more I used it, the more technical debt I accumulated.

This was one of the reasons I wrote zsv (https://github.com/liquidaty/zsv). Maybe csvkit could incorporate the zsv engine and we could get the best of both worlds?

Examples (using majestic million csv):

---

}

```

This of course assumes that each line is a single record, so you'll need some preprocessing if your CSV might contain embedded line-ends. For the preprocessing, you can use something like the `2tsv` command of https://github.com/liquidaty/zsv (disclaimer: I'm its author), which converts CSV to TSV and replaces newline with \n.

You can also use something like `xsv split` (see https://lib.rs/crates/xsv) which frankly is probably your best option as of today (though zsv will be getting its own shard command soon)

wget https://github.com/duckdb/duckdb/releases/latest/download/duckdb_cli-linux-arm64.zip unzip duckdb_cli-linux-arm64.zip sudo mv duckdb /usr/local/bin/

DuckDB ships a shell extension that registers _ as a replacement scan. FROM _ resolves to the result of the previously executed query, surfaced as a one-shot table reference. The reporter on #22852 showed that SELECT d.x FROM _ AS d failed with Referenced table d1 not found. The user-supplied alias d never reached the binder's scope-resolution layer; the previous-result table came out under an internal name.

https://github.com/atuinsh/atuin for fuzzy shell history (ctrl+r)

https://github.com/sharkdp/bat (nice coloured cat replacement)

https://github.com/abiosoft/colima (so I don't need docker desktop)

https://github.com/duckdb/duckdb (performant database that lets you directly query JSON, parquet, csv files with SQL queries and convert one to the other.

https://github.com/eradman/entr (rerun commands automatically when provided files change) (useful for rerunning test commands automatically once you save the file you're editing.

https://github.com/martinvonz/jj and https://github.com/idursun/jjui (Jujutsu VCS, been using it for three months and I really enjoy it)

https://github.com/jesseduffield/lazydocker (managing containers, images, volumes easily)

https://github.com/jesseduffield/lazygit (best tui for git and outside niche git commands, the fastest way to use git.)

https://github.com/jdx/mise (fast asdf, direnv, and task runner replacement) (install pretty much version of tool, language, env vars in a per directory level. (Or global if you want))

https://github.com/ajeetdsouza/zoxide (intelligent cd to move between directories incredibly quickly)

Still no support for range types though, which is a pity as that continues to block me from porting most of my Postgres workloads.

date_ranges are so great, you'll wonder how you ever did without them.

1: https://www.postgresql.org/docs/current/rangetypes.html

2: https://github.com/duckdb/duckdb/discussions/6077

Inspired by the post that's on the front page as I write this [1] I'm interested to hear about who's using DuckDB in production and how.

We have a tool live that uses it and I'm quite happy so I'm both looking for interesting use cases from others but also full disclosure I'm reasonably sure I've just identified today that DuckDB is leaking memory quite seriously [2] so I'm curious to hear if other people have noticed this or if it's maybe something that's not as relevant to others since people might be running DuckDB pipelines in ephemeral envs like lambdas etc. where a memory leak might not matter as much.

[1] https://news.ycombinator.com/item?id=46645176

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

As far as I can tell pretty conclusive results:

https://github.com/duckdb/duckdb/issues/20569

If someone can explain this or has a fix for it I'd love to hear it!

"DuckDB always uses range requests, firstly to query the metadata only, then to fetch the required columns." — PR #5405: HTTP parquet optimizations

Just for context. DuckDB team is consistently ignores any security practices.

The single one method how to install DuckDB on laptop is to run

`curl https://install.duckdb.org | sh`

I've requested to deliver CLI as standard package, they have ignored it. Here is the thread https://github.com/duckdb/duckdb/issues/17091

As you can see that it isn't single slip due to "human factor", but DuckDB management consistently puts users at risk.