We've supported Supabase, Postgres and MySQL for a while. They're fine. They cover most of what people need.

Then we started getting asked about ClickHouse.

ClickHouse is a different animal. It's a database built for one thing: running analytical queries over enormous datasets very fast. Your Postgres instance slows down around 50 million rows. ClickHouse is designed for a billion. The query patterns are different, the architecture is different, and connecting to it requires a completely different approach under the hood.

So we built that approach.

Your SQL stays the same - reference your tables the same way you reference anything else in Sourcetable - but behind the scenes we route the computation directly to ClickHouse and bring back only the results. A GROUP BY over a billion-row events table takes two seconds instead of never finishing.

What "first class" actually means

It means the boring stuff works.

• Natural language → SQL
• Natural language → Python, operating directly on your data
• Add a credential from the chat or from the connectors page — both paths fully sync your schema
• All your tables appear in the @ picker immediately, with column types
• Queries run the same way they do against Postgres — same SQL syntax, same table references, same joins against your other data sources
• The @ mention resolver understands that @my_clickhouse.events means the events table in your ClickHouse credential
• You can join ClickHouse tables against Postgres tables or local files in the same query (requires remote data fetching for now)

The last one still surprises people. Cross-source joins work because Sourcetable handles the coordination - you just write the SQL.

If you have a ClickHouse database and want to try it, add a credential from the connectors page or paste the connection details into the chat. Your tables will appear in the @ picker as the sync completes in the background.