. -->

I created a playground for 110 database systems | ClickHouse<br>Skip to content

Open searchOpen region selectorEnglish<br>Japanese<br>Korean<br>Chinese<br>French<br>Spanish<br>Portuguese<br>Arabic

49kSign inGet Started

->Scroll to top<br>BackBlog<br>Engineering<br>Copy pageCopied!More actionsView as Markdown Open this page in Markdown<br>Open in ChatGPT Ask questions about this page<br>Open in Claude Ask questions about this page<br>Open in v0 Ask questions about this page

I created a playground for 110 database systems

Alexey Milovidov<br>Aug 3, 2026 · 22 minutes read

Here it is: benchmark.clickhouse.com/playground. You can choose any of these hundred database systems and run queries. You can create tables and databases, insert data, drop tables, etc. Every database comes with a preloaded dataset of 100 million records, so you can test example queries. It has not only relational databases, but also unusual ones and systems from an entirely different universe, like BQN. And it provides a "competition" mode, where you can select multiple systems and run a race between them or compare results for correctness.

As far as I know, this is the biggest collection of database systems in an interactive playground. There are similar websites where you can query various databases, like sqlfiddle , db-fiddle , and codapi , but none come close to a hundred systems.

How is it possible #

ClickBench origins #

It originates from the ClickBench project. The benchmark was created in 2013 for comparative testing of ClickHouse, and in 2022 it was extended to an open benchmark for analytical databases. I wanted to test as many databases as I could, so the focus was to make adding a new database easier. Every database was represented as a directory with a couple of shell scripts. The main script installs the system, downloads the data, inserts it, runs the benchmark, and outputs the results. The scripts are run manually on a freshly created EC2 machine. And if we need to test a cloud SaaS database, we record a step-by-step instruction instead of a script.

This gives a lot of flexibility. For example, if a system does not work on an Ubuntu EC2 image, you add an instruction to run it in Docker. If it requires a configuration of an obscure JVM version, you put every step in a script. This approach paid off - with minimal code, it made the benchmark more open for contribution, and today it is the most popular open benchmark for testing analytical databases.

Problems with supporting it #

The question is - how to support a hundred shell scripts, how to keep them up to date? It is easy to spin up an EC2 machine once, copy-paste the script, then copy-paste the results, but doing it repeatedly is not nice. Some results may become outdated, and you want to rerun them. And if you want to change just anything in the benchmark - say, try new queries, or change the location where the data is downloaded, you have to repeat all the work.

So I added some automation over time. In summer 2025, I added a cloud-init script that allows launching a machine and running the benchmark script in an unattended way. The script prints logs with a recognized result format and then uploads the logs to the ClickHouse service. Another script finds new results and updates the repository. Then it was a huge and boring task of updating all the scripts to make sure they could still run.

Now, another problem - what if we want to add new queries or datasets to the benchmark, or create a new benchmark on top of all systems? We have a hundred shell scripts, all of which work, but all of which do repetitive things (like downloading the dataset or running queries) a little bit differently. Even a bigger problem - some contenders were cheating on the benchmark by "forgetting" to flush the page cache between queries, or not including some optimization work into the loading time. Thanks to the contributors, when one contender cheated on the benchmark, another caught them. It is easy to cheat on the benchmark with caching, and we decided to restart every system before each cold query result is measured, so the result will be valid. But how to add restarts to a hundred slightly different shell scripts?

We need to refactor them. Let every system provide a set of scripts implementing a common interface. For example, every directory should contain a query script to run a single query, stop, start, check for restarting, etc. Refactoring a hundred shell scripts is well beyond human capabilities, and I tried to do it multiple times - first manually, then with AI. After a few tries, it was done.

This wasn't easy. ClickBench includes not only real databases, but also database engines without a server. Some of them are building blocks for databases, so when someone wants to build a custom SQL engine, they can build it around Datafusion or DuckDB. Some of them are tools or libraries for data analysis, such as Pandas and Polars. To make the benchmark uniform, these embedded systems are wrapped into a Python...