Renart

Open source alternative to dbt Cloud and Databricks

93 stars
Apache-2.0
Active this week
Last commit 4 days ago

Last verified Oct 19, 2026

Build SQL and Python data pipelines, notebooks, and dashboards in a self-hosted Git-native workspace. Apache-2.0 licensed, currently in public alpha.

Visit website GitHub93 Deploy on Hostinger

Read the full breakdownWho it is for, how it works, trade-offs, the quick start and the FAQ

who it's for

Who Renart is for#

Data engineers building Git-reviewed pipeline definitions

Renart stores every pipeline, notebook, dashboard, and schedule as a plain Git file. Engineers who want SQL transformations and scheduling reviewed through the same PR workflow as application code gain a unified history across the entire data workflow.

Skip if:

Teams that need a production-hardened scheduler today. Renart is in public alpha and the project itself advises against relying on it for critical production scheduling.

Analysts combining SQL notebooks with version-controlled dashboards

Notebooks in Renart share the same typed schema as the pipelines they analyze. Column names and types are visible during notebook editing, and completed analysis can be promoted into pipeline assets or published as version-controlled dashboards.

Skip if:

Teams that need a dedicated BI tool with organization-wide dashboards, access control, and embed support. Renart's dashboard functionality is part of a developer workspace, not a standalone BI product.

Teams evaluating a self-hosted alternative to dbt Cloud

Renart covers the data transformation workflow that tools like dbt Cloud focus on, and extends it with notebooks, dashboards, and data loading in the same local environment. The Git-native storage means the same review workflow applies to all pipeline definitions.

Skip if:

Teams with existing dbt project definitions. Renart uses its own pipeline format and is not a drop-in replacement for dbt projects. Currently in public alpha.

Data teams starting new analytics projects with DuckDB

Renart runs immediately against a local DuckDB database with no external infrastructure. Building a new pipeline from scratch, inspecting the data, writing notebooks, and publishing a dashboard can all happen on a laptop before connecting to a production warehouse.

Skip if:

Teams working with existing high-volume production workloads that need concurrent distributed compute. DuckDB is an in-process database suited for local development; for production scale you will need to connect Renart to an external warehouse.

the problem

The problem it solves#

Data teams working with SQL transformations, notebooks, and dashboards typically split their workflow across separate paid services. Each tool keeps its own state and scheduling, so a schema change in the warehouse requires updates in multiple places. There is no shared history tying the transformation definitions, notebook outputs, and dashboard specs together.

The fragmentation compounds over time. Running a pipeline from data ingestion through transformation and into a dashboard requires hand-offs between tools that were not designed to share context. Type errors caught late mean wasted runs. Teams that want full Git ownership of every artifact in the workflow generally find no single self-hosted path that covers all three stages.

how Renart solves it

How it solves it#

Visual pipeline canvas with dependency tracking

Assets, dependencies, lineage, and staleness are visible together on a canvas. When you change a transformation, Renart highlights every downstream asset that may need rebuilding. Inspect mode lets you preview SQL results against live data before materializing any asset.

Pipeline-aware SQL and Python type checking

SQL completion uses the actual tables and columns the pipeline knows about, not a generic schema. Type diagnostics catch column mismatches before a run reaches the database. Python diagnostics include hover, go-to-definition, and completion as you edit.

Git-native definitions for all workflow artifacts

Pipelines, notebooks, dashboards, reports, and schedule definitions are plain files stored in a Git repository. Every visual edit in the workspace produces a reviewable diff. There is no state hidden in a hosted service and no proprietary format to export from.

Data loading from databases, warehouses, files, and APIs

Connects to Postgres, ClickHouse, Snowflake, BigQuery, Redshift, Databricks, S3/GCS, and HTTP APIs alongside local DuckDB. Loading mode is configured in the workspace, and each transfer is part of the pipeline alongside its downstream transformations.

Notebooks and dashboards alongside pipelines

Notebooks run against the same typed assets as pipelines, so schema changes propagate without reconnecting to a separate environment. Dashboards and reports are version-controlled alongside the pipeline definitions they depend on.

strengths · trade-offs

Strengths and trade-offs#

Strengths

Apache-2.0 license with no account and no subscriptionApache-2.0 permits commercial use, modification, and redistribution. Running Renart requires no account and no hosted control plane. Credentials and run history stay on the machine; only authored definitions go into the repository.
Local-first: starts with DuckDB, connects to any warehouseWorks immediately against a local DuckDB database with no external setup. The same workspace connects to Postgres, ClickHouse, Snowflake, BigQuery, Redshift, Databricks, S3/GCS, and HTTP APIs when you need them. No cloud account is required to begin.
One workspace spanning move, transform, and analyzeLoad, pipeline, notebook, dashboard, and schedule views share the same asset definitions and column schemas. The context you build while transforming data carries over into notebooks and dashboards without reconnecting or re-specifying tables.

Trade-offs

-Public alpha: not suitable for critical production schedulingRenart is in public alpha. The core build, inspect, run, schedule, notebook, type-checking, and freshness workflows are available, but the project warns to expect rough edges and breaking changes before the first stable release. The README explicitly recommends evaluating before relying on it for critical production scheduling.
-Early-stage project with a small contributor baseCreated in April 2026, Renart has 76 GitHub stars and 40 open issues. The contributor community is small at this stage, with no established track record on resolution times. Teams that need a stable, well-supported tool with an established community should wait for the first stable release.

versus alternatives

Renart vs alternatives#

Renart vs dbt Cloud

dbt Cloud is a commercial managed service for data transformations. Renart takes a self-hosted approach to a wider scope: data loading, SQL and Python transformation with type checking, notebooks, dashboards, and scheduling, all stored as plain Git files in a local workspace.

The key differences are deployment model and workflow scope. Renart runs on your machine and requires no account or subscription. All pipeline, notebook, dashboard, and schedule definitions stay in your Git repository. dbt Cloud is a managed cloud service.

Renart suits teams that want the full data workflow in one self-hosted, Git-native environment at no licensing cost. Teams that prefer a managed cloud service for their data transformation layer should evaluate dbt Cloud based on their own requirements.

Renart vs Databricks

Databricks is a commercial data analytics platform. Renart offers a self-hosted approach to SQL and Python pipelines, notebooks, and dashboards with no cloud subscription. Renart can also connect to Databricks as a warehouse, so the two tools are not mutually exclusive: you could use Renart as the local authoring environment while Databricks serves as the compute layer.

The key differences are infrastructure model and cost. Renart runs locally on your machine and connects to the databases and warehouses you configure, including Databricks. All definitions stay in a Git repository under your control.

Renart suits teams that want local-first data engineering with full Git ownership and no cloud subscription. Teams that prefer a managed cloud environment should evaluate Databricks based on their own requirements. Renart's public alpha status means it is not yet ready for production use as a substitute for any managed data platform.

install · quick start

Quick start#

bash

Install Renart with the one-line installer, then start it inside a Git repository.
```bash
curl -LsSf getrenart.com/install.sh | sh
renart
```

tech stack · detected from GitHub

What it's built on#

Languages: GoJavaScriptPythonTypeScript
Frameworks: React

frequently asked

FAQ#

Is Renart ready for production use?

Not yet. Renart is in public alpha, and the project itself warns that rough edges and breaking changes are expected before the first stable release. The README recommends evaluating Renart before relying on it for critical production scheduling. Core workflows including pipelines, notebooks, scheduling, and type checking are available and functional.

What databases and warehouses does Renart connect to?

Renart connects to DuckDB (locally, no setup required), Postgres, ClickHouse, StarRocks, Trino, Snowflake, BigQuery, Redshift, Databricks, S3/GCS, and HTTP APIs. You configure connections in the workspace; credentials stay on the machine and are not part of the authored Git definitions.

How is Renart different from dbt?

dbt focuses on SQL transformations with a compiled, version-controlled approach. Renart covers the broader data workflow, handling data loading, SQL and Python transformations, notebook exploration, and dashboard publishing in one workspace. Everything is stored as plain Git files rather than spread across separate tools.

What license is Renart under?

Apache-2.0, an OSI-approved open source license. It permits commercial use, modification, and redistribution. There is no open core, no managed tier required, and no licensing cost.

Does Renart require an account to run?

No account is required and there is no hosted control plane. Renart runs on your machine and connects to the databases and warehouses you configure. Credentials and run history stay local; only authored definitions (pipelines, notebooks, dashboards, schedules) go into the Git repository.

also worth a look