Replay stored history
Rebuild a table from the source history SQLTide keeps in ClickHouse. Replay can deliver a row twice, so your SQL and table engine need to handle duplicates.
How replay works →Streaming SQL pipelines for ClickHouse
Write each step of your pipeline as SQL. When you change a step, SQLTide can build the new version alongside the running one and fill it with the events already stored in ClickHouse. Check the results, then point your queries at the new version.
pip install sqltideamount_cents >= 0 → >= 100SELECT * FROM tbl__order_report
Reads the current version
Compare the two versions. Your queries still read the current one, and both keep getting new events.
By default sqt build drops the selected tables and refills them in place, while queries keep reading them. In virtual mode it builds next to the current tables instead, so you can check a change before your queries move to it. The steps below follow virtual mode.
Each model is a SQL file with typed columns. sqt compile checks them on your machine, without connecting to ClickHouse.
sqt plan lists the tables a change rebuilds and the history it replays. It doesn’t change anything in ClickHouse.
In virtual mode, sqt build creates the new tables next to the current ones and fills them. Your queries keep reading the current version while you compare.
Promoting points the views your queries read at the version you checked. A build never does this on its own.
Promote a version →Rebuild a table from the source history SQLTide keeps in ClickHouse. Replay can deliver a row twice, so your SQL and table engine need to handle duplicates.
How replay works →Write SQL tests with fixed inputs and run them before you deploy.
sqt testA local UI shows your models, sources, runs and deployments.
sqt devLook around the UI in your browser, or run the playground on your machine with Docker.
pip install sqltide
sqt playgroundsqt playground creates a small orders project and starts ClickHouse for it. How the playground works →