dbt in Syne: connect your models, analyze the data, review the change

dbt projects, including dbt Cloud analysis, manifest imports, GitHub compilation, and team-managed runners, require Syne Pro or an eligible trial.

Your team already has dbt models. The next question might be simple: which customers account for most of our revenue? Answering it should start with the definitions your team maintains, alongside the data those models produce.

The Syne dbt preview connects those two pieces. Bring in metadata from dbt Cloud or a manifest and analyze built models in your PostgreSQL warehouse. Connect GitHub when you also want on-demand compilation and schema-change review. Keep production builds and schedules in your existing dbt environment.

This article describes the PostgreSQL preview implementation. Availability depends on your Syne deployment; it is not a general-availability announcement. The illustrations and revenue values below are examples, not customer data or production screenshots.

Start with the connection your team needs

There are three ways into the workspace. You do not have to connect source code to ask a question about an existing model.

Your team wants to…	Connect	Keep running elsewhere
Analyze models built by dbt Cloud	A dbt Cloud read token, account and job, plus the PostgreSQL warehouse	dbt Cloud jobs and schedules
Analyze models built in CI, locally, or another platform	manifest.json plus the PostgreSQL warehouse	Your existing build environment
Inspect source changes and govern their database impact	A GitHub project plus the PostgreSQL warehouse	Source editing, pull requests, production builds, and schedules

The distinction matters: dbt Cloud provides the model metadata, while your warehouse stores the model rows. A metadata connection does not move the data into Syne or grant new database permissions.

Walk through an existing-model analysis

Suppose your project builds analytics.customer_revenue, with customer_id and lifetime_revenue. Its upstream stg_orders model contains the order amounts used in that calculation. These are sample names; select the relations and columns from your own project.

1. Connect the metadata and warehouse

As a team admin, open Database tools > dbt > Connect project. Choose dbt Cloud, give the project a name, and select the existing PostgreSQL connection containing the built models. Enter your account hostname, account ID, job ID, and a token that can read that job and its artifacts.

Syne verifies the job and reads manifest.json from the latest successful run. It makes GET requests only and records the run ID with the snapshot. It does not start a dbt job. If initial refresh fails, the project remains connected so you can repair access and retry.

For a project built elsewhere, choose Import manifest and upload the artifact from your existing environment. That path needs neither GitHub nor a platform token. Re-import when the model definitions change. Both paths are covered in the existing-model connection guide.

2. Inspect what the model means

Select customer_revenue. Read the description, declared columns, and upstream dependencies. Check which artifact supplied this context. For dbt Cloud, the provider run ID helps you trace the metadata back to the selected job. Imported manifests are labeled as supplied by your team.

A model name alone is not a metric definition. Check whether revenue includes refunds, which currency it uses, and which orders it excludes. Kole can help explain definitions that are present, and identify questions the metadata cannot answer.

3. Query the built relation

Open Analyze data. Use Start with selected model to insert the relation, then write the analysis:

select
  customer_id,
  lifetime_revenue
from analytics.customer_revenue
order by lifetime_revenue desc

Syne runs the query through its existing database bridge with the requesting user's identity, read-only enforcement, masking, and an audit record. The editor displays up to 200 rows. That result cap does not limit how many warehouse rows an aggregate scans, so choose sensible filters for large models.

The example returns customers 1001, 1002, and 1003 with illustrative lifetime revenue values of 12,480, 8,250, and 6,720. The query orders a model that already exists; it neither compiles source nor creates the table.

4. Ask Kole to continue the analysis

Try: “Use the current dbt metadata to show the top customers by lifetime revenue. Show the SQL and explain how the model calculates revenue.”

Kole can inspect the project, retrieve model context, and run a read-only query through the same frontend APIs. Its dbt query tool supports joins and aggregations across accessible built relations. If you ask for a regional breakdown, it should first find a documented customer-region relation and join key, rather than inventing them.

Metadata refresh remains manual. A failed refresh preserves the last successful snapshot. That snapshot may be useful context, but it is not evidence that the warehouse is fresh or that data tests passed. After changing project settings, refresh or import metadata again before querying.

Connect GitHub when the question becomes a source change

Some questions lead to a proposed model or database change. For that workflow, connect a GitHub repository, ref, and project folder to the PostgreSQL connection. GitHub remains the source of truth. Syne resolves the ref to an immutable commit and attaches it to compilation history.

Choose the team's connected GitHub App to reuse its repository inventory and installation flow. The picker supports search, paging, and access sync. Syne requests a short-lived read-only token scoped to that repository; you do not need another personal token. Existing projects can switch to App access in settings. Enabling SQL pull-request reviews is a separate choice.

If App access is disconnected or suspended, a repository is removed, or a sync detects a rename, Syne invalidates the affected source binding and cancels active compilations. Reconnect the source and request a new compilation when access is restored.

Request compilation to inspect generated SQL and model dependencies. Compare resources added, removed, or changed since the previous successful snapshot. Preview a built relation or a compiled SELECT through the read-only database bridge.

When a database migration is needed, propose a schema-change ticket with explicit SQL, a reason, and optional rollback SQL. The model, compilation, and commit travel with the ticket into Syne's existing review workflow. Ticket creation does not execute the migration or open a pull request.

Kole can help draft documentation, tests, and migration SQL. Compilation and ticket creation pause for human approval. Analysis-only dbt Cloud and manifest connections keep these source actions out of their workspace.

Compile on Syne or bring your own machine

The hosted compiler is designed for small PostgreSQL projects. It runs in a short-lived offline container with 1 CPU, 512 MB of memory, and up to 220 seconds of dbt process time. It returns earlier when compilation finishes. If the process reaches the limit, the request fails without deploying models. Container startup, source retrieval, transfer, and cleanup add time around the process itself.

For larger projects, teams can connect a dedicated Linux machine running Docker and gVisor. The runner polls Syne over outbound HTTPS, checks a mandatory repository allowlist, and downloads the pinned source using a local GitHub read token. Each compilation runs in a separate offline sandbox without that token or warehouse credentials.

Team runners default to 2 CPU, 4 GB, and a 15-minute process limit. Configure up to 16 CPU, 16 GB, and 30 minutes for a larger project. Each runner identity processes one job at a time. Syne exposes online status, pause, cancellation, credential rotation, and revocation. Artifacts identify the team runner that supplied them; they are not an attestation of an unmodified compiler.

The runner installation guide includes host requirements, a Compose download, configuration, lifecycle controls, and operator setup. The compiler images are currently private, so package access is required before onboarding a runner.

What this preview covers

This release brings model context, governed analysis, isolated compilation, and reviewed changes together. Its current scope is PostgreSQL. Production builds, schedules, runner autoscaling, repository hosting, and GitHub write-back remain outside the preview.

Offline compilation cannot perform warehouse introspection, install packages, execute Python models, or use custom adapters. Vendor packages into source or import a compatible manifest produced in the existing environment. A successful compilation means an artifact was produced; it does not prove SQL execution, materialization, passing tests, or freshness.

Start with the dbt product page and setup documentation. Choose the existing-model path for analysis, and add a separate GitHub connection when your team needs source compilation and review.

Shared managed compilation

Syne deployments can enable a shared worker pool across teams. Compilation requests wait in a durable queue, with one active pool job per team and a global capacity limit. Each worker provisions a fresh gVisor compiler container per job and removes it afterward. Operators scale worker replicas in the main Compose deployment; this does not automatically provision virtual machines. Customer-owned team runners remain available.