Cool idea, I've always wondered what it would look like to build a relatively large DB heavy stack where you use only standard SQL. I like the concept of being able to switch out DBs if you want to run it in different contexts (maybe SQL lite for local dev etc) and all your migrations etc would just work out of the box.

But I mean, that would probably be sort of a nightmare to make happen in practise. You'd need everyone that touches the code base to understand and accept that constraint, you'd probably be leaving a bunch of performance on the table without using DB specific features and it would drastically increase the test surface I suppose.

It's just a thought, I've never come across a situation where this would be worth doing over just sticking to a single provider but I'm interested to know if there are.

Also heads up, I tried to use the codapi C# playground and just get a "code execution timeout" every time. :)

I've been recently toying around with dynamically switching between DuckDB and BigQuery on query time. So you have a layer of standard SQL in front, which uses sqlglot to translate it to compute-specific SQL. So e.g. you can use DuckDB for development or low to medium-sized datasets, and switch to BQ for big datasets.

In theory, it sounds great, but in practice you indeed lose database-specific operators, you should restrain from using database-specific optimisations, etc...

I am building a SQL like query engine with a typescript query builder. It aims to provide multidimensional query capabilities (think about olap cube). The query engine is compatible with several databases (sucks, clickhouse, bigqueryx, snowflake...). Our users are developers building decision making applications. They are using for instance duckdb to develop locally their application and use a cloud provider in production. Here's the link https://github.com/squashql/squashql. Feel free to ask me any questions.

SQL Polyglot is really more of an education/exploration thing.

And yes, I should definitely increase the C# sandbox timeout. Will do :)

Yeah understood, the tool itself is cool. I think it will be something I keep bookmarked and check out when I’m working with a feature or sql syntax I’m not familiar with to see how it differs (or not) across dbs. Thanks for making it.

That's where an ORM makes a world of difference.

Very cool. So many times I was wondering if database X supports particular SQL feature of function and if it works the same way. This makes it very easy to do

Cool! Is this built with sqlglot[1] on the back end?

[1] https://github.com/tobymao/sqlglot

It's https://github.com/nalgeon/codapi

CodAPI looks like a nice tool to showcase code without getting into Jupyter/Colab. Syntax highlighting would be great to have.

This is what Substrait and Apache Arrow seek to solve; but by serializing query plans that can be produced/consumed by different engines. It’s like an IR for sql.

https://substrait.io/

Wonder if you could put all those databases in a Linux image and boot it using v86 [0], eliminating the need for a server.

[0] https://github.com/copy/v86

I haven't really used it but could this be used as a ground-truth for SQL something like how OpenAI Code Interpreter / Advanced Data Analysis is used for python?

There is no ground truth in SQL. I mean, there is a standard, but none of the vendors bother to implement it.

What SQL Polyglot can do is help you quickly check if certain database engines support a certain SQL feature.