This is mostly right, but there are quite a few important caveats here. > And third this project only has builtin support for querying CSV and JSON files. Th

This is mostly right, but there are quite a few important caveats here. > And third this project only has builtin support for querying CSV and JSON files. This is actually not true :) There's also Parquet, and you can read arbitrary text files line by line (which with soon-to-come regex capture should let you easily work with all kinds of textual log files). Other than that, there are plugins for other databases which are intentionally kept out of the core. > 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. Looks like a bug in the docs datasource, thanks! Already diagnosed the issue and it should be fixed soon. > It will support a limited subset of SQL. It's not really a subset. It also has extensions not available in standard SQL like temporal SQL, as well as ergonomic handling of columns with multiple possible value types (I.e. a String | Int column), which is a common occurrence in i.e. JSON files and is not well-solved by standard SQL. There are many features currently in OctoSQL and that I'm planning to add in the future that wouldn't be possible with the SQLite approach, nor with the Steampipe Postgres approach. Simple example: tailing a log file live while filtering lines using SQL. But yeah! Overall there are definitely tradeoffs, and you should choose the tool that makes sense for you. After I'm done stabilizing the core I will move on to implementing a ton of functions available in other engines, so that should cease to be an issue soon as well - there's not that many of them, it just hasn't been a priority so far.