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.
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.
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. :)