3,300 stars · Apache-2.0 from the About sidebar on 28 October 2026 and from the package index page; the README adds that the documentation is under CC-BY-4.0. · v0.236.4 (2026-10-22) · Track this in Rising ↗
Plans, tests and applies changes to a chain of database queries, describing what a change would affect before anything runs.
Radar check
What we found when we opened it. Every bar is one fact, with its date.
Last code pushed 26 Oct 2026, one day before this check.
Latest release v0.236.4 on 22 Oct 2026.
Public since September 2022, about 4 years.
3,337 stars and 483 forks.
103 commits and 62 new issues in the last 90 days.
184 contributors. 103 pull requests merged in 90 days.
A security policy says how to report a problem. No published security advisories.
How the bars are scored
- Alive. Days since the last code push: a week or less 100, a month 90, three months 70, six months 50, a year 30, eighteen months 15, older 0.
- Releases. Age of the latest GitHub release, on a similar scale; no bar when the project publishes no releases.
- Maturity. Age of the project: eight years 100, five 90, three 70, two 55, one 40, six months 25, younger 10.
- Adoption. Stars on a log scale: 100,000 stars is 100, 10,000 is 80, 1,000 is 60, 100 is 40.
- Activity. Commits in the last 90 days: 300 or more 100, 100 85, 30 65, 10 45, any 25.
- Community. People who have contributed: 100 or more 100, 30 80, 10 60, 5 40, 2 25, one 10.
- Security. A published security policy 80, none 40; published advisories are listed, not scored.
Checked by Repo Radar on 28 Oct 2026 from the repository on GitHub. Covered in Edition 64.
▶Repo detailsthe review · specs · pros & cons · install
What it does
It takes the queries that build a company's tables, written in SQL or Python, and treats them as a set of models with known dependencies. The central command is plan, which compares what the code now says against what has already been built, works out what would have to change, and prints that for a person to approve before anything runs. The project compares this to the plan-and-apply pattern used by infrastructure tools, which is the right comparison. Development happens in what it calls a virtual environment: a separate copy of the whole chain that reuses the existing tables wherever the code is unchanged, so making one costs almost nothing. It can run unit tests against a model with sqlmesh test, run data checks it calls audits, show the difference between two versions of a table, work out which column came from which earlier column, and translate a query written in one database's dialect into another's across more than ten dialects. Engine support includes BigQuery, Snowflake, Databricks, Redshift, Athena, Trino, Postgres and DuckDB. Version 0.236.4 was published on 22 October 2026 and it needs Python 3.9 or newer. It stores no data of its own, it does not move data in from other systems, and it does not replace a scheduler for anything outside its own runs.
Why it matters
Who it suits. A small data team that has outgrown a folder of scripts and is now afraid to change any of them. The specific pain this answers is the one where a change looks fine, is applied, and three reports break the next morning. It also suits anyone paying per query on a cloud warehouse, because the cheap development copies remove the usual habit of rebuilding everything to test a change. Skip it if the work is one dashboard over one table, since this is machinery for a chain of them.
Verdict. The most interesting fact in today's twelve is not a feature. The repository has moved out of the company's own account and its README now states that it is a project of the Linux Foundation, which for a tool sitting at the centre of a company's reporting is the thing worth knowing: a foundation does not get bought. The software itself is good and the plan command is the part that justifies it, because approving a described change is a different activity from running a script and watching. Three cautions. It is young by the standards of the thing it replaces, with 206 open issues. The documentation assumes some fluency with the vocabulary of data modelling, so a complete beginner will struggle. And its claimed compatibility with the established alternative is real but not total, and the project publishes no list of the gaps, so a migration needs a trial rather than a plan. dbt-labs/dbt-core is that established alternative and the honest default for most teams; dagster-io/dagster solves the neighbouring problem of running the whole thing on a schedule.
Summary (Key Points)from the README
Key features
- Change impact in the CLI and IDE: Shows the SQL impact and context of your changes, both in the CLI and in the SQLMesh VSCode Extension.
- Virtual Data Environments: Creates isolated development environments without data warehouse costs.
- Plan/Apply workflow: Works like Terraform, so you can see the potential impact of changes before applying them.
- CI/CD bot: An easy-to-use bot for blue-green deployments.
- Unit test generation: A command generates a unit test file (for example, test_stg_payments.yaml in the tests/ folder) by running a live query to produce the model's expected output.
- Efficient builds: Never builds a table more than once, and for incremental models it runs only the transformations needed for modified data.
- Table diffs: Runs table diffs between prod and dev for the tables and views affected by a change.
- SQL transpilation: Write SQL in any dialect and SQLMesh transpiles it to your target dialect before sending it to the warehouse, with error debugging across 10+ SQL dialects.
- Column-level lineage: Shows the impact of changes before you run them in your warehouse.
Important
- Python install: You may need to use python3 or pip3 instead of python or pip, depending on your Python installation.
- Windows setup: The README has a Windows Installation heading but gives no instructions under it, so check the quickstart guide or documentation for Windows steps.
- Documentation pointers only: The README points to external quickstart, crash course, and walkthrough material rather than detailing usage itself.
- Contribution requirements: Contributions require DCO sign-off, and the README asks you to review the Code of Conduct and Governance documents.
- Licensing: The code is licensed under Apache License 2.0, and the documentation is licensed under CC-BY-4.0.
Written by an AI model from the project’s README; not part of the review, and it can be wrong.
- The plan command describes a change before applying it, which turns a risky edit into a review.
- Development copies of the whole chain are nearly free, so testing does not mean rebuilding.
- Now a Linux Foundation project, which settles the usual worry about a single company owning it.
- 206 open issues and a young project, against alternatives with years more use behind them.
- The documentation assumes the reader already knows the vocabulary of data modelling.
- Compatibility with the established alternative is partial and the gaps are not listed anywhere.
- dbt-labs/dbt-core
The established tool for the same job, far more widely used, with no equivalent of the plan step.
Track this in Rising ↗ - dagster-io/dagster
Organises data work around the tables it produces and runs it on a schedule: the neighbouring problem.
Track this in Rising ↗
python3 -m venv venv source venv/bin/activate pip install "sqlmesh[duckdb]"
