OctoSQL is an awesome project and Kuba has a lot of great experience to share from building this project I'm excited to learn from. And while building a custom

OctoSQL is an awesome project and Kuba has a lot of great experience to share from building this project I'm excited to learn from. And while building a custom database engine does allow you to do pretty quick queries, there are a few issues. First, the SQL implemented is nonstandard. As I was looking for documentation and it pointed me to `SELECT * FROM docs.functions fs`. I tried to count the number of functions but octosql crashed (a Go panic) when I ran `SELECT count(1) FROM docs.functions fs` and `SELECT count(*) FROM docs.functions fs` which is what I lazily do in standard SQL databases. (`SELECT count(fs.name) FROM docs.function fs` worked.) This kind of thing will keep happening because this project just doesn't have as much resources today as SQLite, Postgres, DuckDB, etc. It will support a limited subset of SQL. Second, the standard library seems pretty small. When I counted the builtin functions there were only 29. Now this is an easy thing to rectify over time but just noting about the state today. And third this project only has builtin support for querying CSV and JSON files. Again this could be easy to rectify over time but just mentioning the state today. octosql is a great project but there are also different ways to do the same thing. I build dsq [0] which runs all queries through SQLite so it avoids point 1. It has access to SQLite's standard builtin functions plus a battery of extra statistic aggregation, string manipulation, url manipulation, date manipulation, hashing, and math functions custom built to help this kind of interactive querying developers commonly do [1]. And dsq supports not just CSV and JSON but parquet, excel, ODS, ORC, YAML, TSV, and Apache and nginx logs. A downside to dsq is that it is slower for large files (say over 10GB) when you only want a few columns whereas octosql does better in some of those cases. I'm hoping to improve this over time by adding a SQL filtering frontend to dsq but in all cases dsq will ultimately use SQLite as the query engine. You can find more info about similar projects in octosql's Benchmark section but I also have a comparison section in dsq [2] and an extension of the octosql benchmark with different set of tools [3] including duckdb. Everyone should check out duckdb. :) [0] https://github.com/multiprocessio/dsq https://github.com/multiprocessio/dsq [1] https://github.com/multiprocessio/go-sqlite3-stdlib https://github.com/multiprocessio/go-sqlite3-stdlib [2] https://github.com/multiprocessio/dsq#comparisons https://github.com/multiprocessio/dsq#comparisons [3] https://github.com/multiprocessio/dsq#benchmark https://github.com/multiprocessio/dsq#benchmark*