As a daily user of xsv, I can't imagine why a CSV processor would need to be competing with SQLite in terms of performance. For me, xsv hits the right niche in

As a daily user of xsv, I can't imagine why a CSV processor would need to be competing with SQLite in terms of performance. For me, xsv hits the right niche in 2 very important and frequent use-cases: 1. One-off analyses or tasks involving relatively small datasets, like trimming the output of a command-line Twitter tool into xargs to, say, unfollow everyone who hasn't tweeted this year, or isn't following me and has fewer than 100 followers. If I were attempting to do a deeper analyses, SQLite would be better (because of the query syntax), but xsv/csvkit works incredibly well for quick explorations/filtering/sorting. Here's an example using csvkit (haven't quite gotten used to all of xsv's syntax) and the t command-line tool: https://gist.github.com/dannguyen/7213b16b7de79ad9c89fc2297d0c822d https://gist.github.com/dannguyen/7213b16b7de79ad9c89fc2297d... 2. Prepping data for importing into SQLite; for very large public datasets, I like using xsv/csvkit to trim columns and filter out rows before importing them into SQLite. This is especially convenient since SQLite doesn't allow for dropping columns once a table is created. If I'm ever working with data big enough to need SQLite-like performance, then I probably need SQLite's query syntax and other features. xsv is already flexible and performant for what I need in my data pipeline.