go-sqlite3-stdlib VS octosql

Adding user-defined functions to SQLite is not difficult, and the mechanism is quite flexible. You can create extensions and load them when you create the SQLite connection to have the functions available in queries. I wrote a blog post explaining how to do that using Rust, and the example is precisely a `regex_extract` function [0].

If you need them, you also have a "stdlib" implemented for Go [1] and a pretty extensive collection of extensions [2]

[0]: https://ricardoanderegg.com/posts/extending-sqlite-with-rust...

[1]: https://github.com/multiprocessio/go-sqlite3-stdlib

[2]: https://github.com/nalgeon/sqlean

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

[1] https://github.com/multiprocessio/go-sqlite3-stdlib

[2] https://github.com/multiprocessio/dsq#comparisons

[3] https://github.com/multiprocessio/dsq#benchmark

Hey Kuba!

> Especially on the community building aspect, it's really impressive that you've been able to spark so many communities on various platforms (Reddit, GitHub, Discord, etc.)!

Yeah it's been so cool to see so many people come together, hobbyists and professionals.

> On a more technical note, since dsq is based on the "load it into SQLite and query it from there" architecture, have you considered integrating with the plugin ecosystems of other existing projects based on that same architecture, like Datasette[0]? It seems like a way to add a lot of value to your tools without much work.

Interesting idea! I haven't looked into Datasette too much. And I haven't thought about plugins too much either. The most I've done is extend the SQLite standard library [0] and I hope to continue growing that. I'd be curious to hear what specifically people like from Datasette they'd like to see in dsq.

> On a more commercial note, overall I think tools like this are very hard to monetize, because right now they're just a fairly niche use case, between - as you mentioned - full blown data analytics platforms and observability query systems, as well as standard unix tools. Especially since if you need the analytics a lot, you'll probably have time to integrate it into your preferred analytics solution (like BigQuery). Do you have any thoughts on that?

My idea was always to focus on smaller and less mature organizations, probably ones that have been around for 10+ years. They aren't using BigQuery, they prefer to host everything themselves, and they don't yet realize there are tools like DataStation that they can easily run to make analytics easier.

I've worked at a bunch of companies like this so I know the market exists. Actually I have been surprised how many people outside of this market showed up in the DataStation community. I've seen Googlers, MS-ers, modern startups, data science teams show up interested in DataStation compared to what they're already using.

For me it's just been a matter of time (and funding) to build out the product to serve these communities commercially as a SaaS or enterprise product.

[0] https://github.com/multiprocessio/go-sqlite3-stdlib

Never got it to anything close to a finished state, instead moving on to doing the same prototype in llvm and then cranelift.

That said, here's some of the wazero-based code on a branch - https://github.com/cube2222/octosql/tree/wasm-experiment/was...

It really is just a very very basic prototype.

This is really cool!

With their Postgres scanner[0] you can now easily query multiple datasources using SQL and join between them (i.e. Postgres table with JSON file). Something I strived to build with OctoSQL[1] before.

It's amazing to see how quickly DuckDB is adding new features.

Not a huge fan of C++, which is right now used for authoring extensions, it'd be really cool if somebody implemented a Rust extension SDK, or even something like Steampipe[2] does for Postgres FDWs which would provide a shim for quickly implementing non-performance-sensitive extensions for various things.

Godspeed!

[0]: https://duckdb.org/2022/09/30/postgres-scanner.html

[1]: https://github.com/cube2222/octosql

[2]: https://steampipe.io

Congrats on the Show HN!

It's great to see more tools in this area (querying data from various sources in-place) and the Lambda use case is a really cool idea!

I've recently done a bunch of benchmarking, including ClickHouse Local and the usage was straightforward, with everything working as it's supposed to.

Just to comment on the performance area though, one area I think ClickHouse could still possibly improve on - vs OctoSQL[0] at least - is that it seems like the JSON datasource is slower, especially if only a small part of the JSON objects is used. If only a single field of many is used, OctoSQL lazily parses only that field, and skips the others, which yields non-trivial performance gains on big JSON files with small queries.

Basically, for a query like `SELECT COUNT(*), AVG(overall) FROM books.json` with the Amazon Review Dataset, OctoSQL is twice as fast (3s vs 6s). That's a minor thing though (OctoSQL will slow down for more complicated queries, while for ClickHouse decoding the input is and remains the bottleneck).

[0]: https://github.com/cube2222/octosql

To add somewhat of a counterpoint to the other response, I've tried the Steampipe CSV plugin and got 50x slower performance vs OctoSQL[0], which is itself 5x slower than something like DataFusion[1]. The CSV plugin doesn't contact any external API's so it should be a good benchmark of the plugin architecture, though it might just not be optimized yet.

That said, I don't imagine this ever being a bottleneck for the main use case of Steampipe - in that case I think the APIs themselves will always be the limiting part. But it does - potentially - speak to what you can expect if you'd like to extend your usage of Steampipe to more than just DevOps data.

[0]: https://github.com/cube2222/octosql

[1]: https://github.com/apache/arrow-datafusion

Disclaimer: author of OctoSQL

Actually, folks just use gRPC or Yaegi in Go.

See Terraform[0], Traefik[1], or OctoSQL[2].

Although I agree plugins would be welcome, especially for performance reasons, though also to be able to compile and load go code into a running go process (JIT-ish).

[0]: https://github.com/hashicorp/terraform

[1]: https://github.com/traefik/traefik

[2]: https://github.com/cube2222/octosql

Disclaimer: author of OctoSQL

Through more magic, you COULD of course use stuff like Spark, or easier with programs like TextQL, sq, OctoSQL.

The logo was created for OctoSQL and in the article you can find a lot of sample phrase-image combinations, as it describes the whole path (generation, variation, editing) I went down. Let me know what you think!

Hey, author here, happy to answer any questions!

The logo was created for OctoSQL[0] and in the article you can find a lot of sample phrase-image combinations, as it describes the whole path (generation, variation, editing) I went down. Let me know what you think!

[0]:https://github.com/cube2222/octosql