Registry / data / sqlmesh

sqlmesh

JSON →
library0.235.4pypypi✓ verified 85d ago

SQLMesh is a next-generation data transformation framework designed to ship data quickly, efficiently, and without error. It enables data teams to run and deploy data transformations written in SQL or Python with visibility and control, supporting concepts like virtual data environments, automated testing, and CI/CD. It is backwards compatible with dbt and focuses on semantic understanding of SQL. The project maintains an active development cycle with frequent releases, with 0.234.0 being the latest stable version.

pip install sqlmesh
INSTALL
IMPORT
SIG · SQLMESH
S
sqlmesh
datapythonv0.235.4
Install
21.0s avg
Import
5129ms
Disk
518MB
Pass rate
5/ 10
Env Coverage5 / 10
glibc
3.93.13
musl
3.93.13
Install & Compatibility
Where this runs
tested against v0.235.4 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
musl
py 3.103.960 runs
build_error
glibc
py 3.103.960 runs
installs and imports cleanly · install 21.0s · import 5.129s · 511MB
518MB installed
● package 518MB
Code
Verified usage

Verified import paths — ran on the pinned version, not inferred.

model
from sqlmesh import model
ExecutionContext
from sqlmesh import ExecutionContext
Config
from sqlmesh.core.config import Config
exp
from sqlglot import exp

The most common way to get started with SQLMesh is via its CLI. This quickstart demonstrates how to initialize a new project using DuckDB as the local engine and then run your first plan. The `sqlmesh init duckdb` command scaffolds a project, and `sqlmesh plan` shows the proposed changes. For a fully runnable example demonstrating project setup and execution, refer to the official documentation.

import os # Ensure SQLMesh is installed along with the DuckDB extra # pip install "sqlmesh[duckdb]" # Initialize a new SQLMesh project with DuckDB as the engine # This creates a 'sqlmesh_example' directory with project files # and sets up a DuckDB connection. # os.system("sqlmesh init duckdb --path sqlmesh_example") # Navigate into the project directory (conceptually, in a real script you'd use os.chdir or similar) # In a terminal, you would run: # cd sqlmesh_example # sqlmesh plan # Simulate a SQL model file: models/full_model.sql # -- models/full_model.sql # -- MODEL ( # -- name sqlmesh_example.full_model, # -- kind FULL # -- ); # -- SELECT # -- 1 AS id, # -- 'A' AS value; # To run the plan and apply changes (requires a project initialized by 'sqlmesh init'): # print("\n--- Running sqlmesh plan ---") # if os.path.exists('sqlmesh_example'): # os.chdir('sqlmesh_example') # os.system('sqlmesh plan --no-gaps --auto-apply') # print("\n--- Querying the created model (requires DuckDB CLI or connector) ---") # # You can query the model using duckdb CLI if installed: # # os.system('duckdb sqlmesh.db "SELECT * FROM sqlmesh_example.full_model;"') # else: # print("Please run 'sqlmesh init duckdb' in your terminal first to create the example project.") print("To get started, run 'sqlmesh init duckdb' in your terminal, then 'cd sqlmesh_example' and 'sqlmesh plan'.") print("This will create an example project and show you the execution plan.")
sqlmesh --version
Debug
Known issues
breakingFrequent updates to the underlying `sqlglot` library (as seen in chore commits like 'bump sqlglot to v30.4.2') can introduce subtle breaking changes or altered SQL parsing/transpilation behavior. While SQLMesh aims to abstract this, it's crucial to review release notes for `sqlglot` when upgrading SQLMesh.
fix
Always check the SQLMesh and SQLGlot changelogs before upgrading. Test your SQLMesh project thoroughly after an upgrade, especially if it involves `sqlglot` bumps, to catch any parsing or transpilation regressions.
affects: All versions, due to frequent `sqlglot` updates. Specifically, `v0.234.0` included a `Fix!: Include custom audit args in the metadata hash` that affects metadata hashing.
gotchaSQLMesh previously had compatibility issues with `pandas` version 3, requiring users to explicitly exclude it. While this might be resolved in future versions, `pandas` compatibility can be a recurring issue with rapidly evolving libraries.
fix
Ensure your `pandas` version is compatible with your SQLMesh installation. Check the official SQLMesh documentation or GitHub issues for known `pandas` compatibility concerns and required version ranges.
affects: Reported in `v0.228.5`, which 'Exclude pandas 3'. Check current compatibility notes for `pandas` >= 3.0.0.
gotchaSQLMesh is inherently stateful. While it can use local databases like DuckDB for development state, production deployments should use robust OLTP databases (e.g., PostgreSQL, MySQL) to store state for ACID transactions, performance, and reliability. Using a local file-based database for shared production state can lead to data integrity issues.
fix
Configure a persistent and reliable OLTP database (e.g., PostgreSQL) for SQLMesh state in production environments by specifying `state_connection` in `config.yaml`.
affects: All versions where state management is used.
gotchaThe `sqlmesh plan` command defaults to targeting the `prod` environment. Accidentally running `sqlmesh plan` without specifying a development environment can inadvertently target or interfere with your production data if not careful.
fix
Always explicitly specify your development environment when running `sqlmesh plan` (e.g., `sqlmesh plan dev_myuser`). Consider changing the default environment in your project's `config.yaml` if all users work in isolated dev environments.
affects: All versions. Default behavior.
gotchaSQLMesh infers schema information from your models. When selecting from external data sources (tables not defined within your SQLMesh project), it may issue warnings about missing schema knowledge, impacting lineage and optimization capabilities.
fix
Use `sqlmesh create_external_models` or manually define external models (e.g., in `schema.yml`) to provide SQLMesh with schema information for external data sources. This enables full column-level lineage and better optimization.
affects: All versions. Default behavior when external sources are used.
gotchaWhile SQLMesh automatically infers column names and types, explicit type casting and column definition in SQL models (e.g., `SELECT o.customer_id::TEXT`) is a best practice. Relying solely on `SELECT *` can lead to unexpected schema changes or hinder SQLMesh's ability to precisely detect breaking changes, potentially causing unnecessary recomputations or data issues.
fix
Explicitly define column names and types in your SQL models, particularly in the final `SELECT` statement. Avoid `SELECT *` in production models where schema stability is critical. Manually specify `columns` in the model definition if schema inference is problematic.
affects: All versions.
Errors
Common errors & fixes
ModuleNotFoundError: No module named 'sqlmesh'
The `sqlmesh` Python package is not installed in the current environment.
fix
pip install sqlmesh
psycopg2.OperationalError: could not connect to server
SQLMesh failed to establish a connection to the PostgreSQL database server, likely due to incorrect configuration, an inactive server, or network issues.
fix
Verify the PostgreSQL server is running and accessible, and check the connection details (host, port, user, password) in your `sqlmesh.yaml` configuration.
sqlmesh.core.errors.ConfigError: Model 'my_model_name' not found in project.
A SQLMesh model or macro attempts to reference another model that does not exist or is not visible within the current project configuration.
fix
Ensure the referenced model (`my_model_name`) is correctly defined, its file is in the project path, and there are no typos in its name.
jinja2.exceptions.TemplateSyntaxError:
There is a syntax error in the Jinja templating used within a SQLMesh SQL model or macro definition.
fix
Carefully review the Jinja template syntax in your SQLMesh model, paying attention to blocks, variables, filters, and macro calls.
Upgrade
Version history
0.235.4latest on PyPI · released Jun 11, 2026
Audit
Dependencies
sqlglotrequiredCore SQL parsing and transpilation engine.
pandasoptionalUsed for Python models returning DataFrames.
duckdboptionalCommon local database engine for quickstart and testing.
psycopg2-binaryoptionalPostgreSQL database connector (example, other DBs require their own connectors).
Agent activity
28 hits · last 30 days
node
22
OpenAI (training)
1
Resources