# dbt Consulting and Data Transformation Services | SynconAI

> dbt consulting and data transformation: dbt Core and the dbt platform, models, tests, sources, docs, CI on pull requests and the Semantic Layer on your warehouse.

Publisher: SynconAI
Canonical HTML: https://synconai.com/dbt-consulting
Markdown cite: https://synconai.com/dbt-consulting.md
Contact: contact@synconai.com · +61 2 7813 0221

## What is dbt data transformation?

dbt data transformation is the practice of building warehouse transformations as a dbt project: SQL models in staging, intermediate and mart layers, declared sources with freshness checks, data and unit tests, generated documentation, CI that builds and tests changed models on every pull request, and shared metrics in the dbt Semantic Layer. It runs on dbt Core or the dbt platform against Snowflake, Databricks, BigQuery, Postgres and other warehouses. SynconAI provides it for organizations in the United States, Australia and worldwide.

- dbt turns SQL select statements into tables and views in your warehouse, in the right order, from files kept in Git.
- Every model can carry tests and documentation, so changes are checked and explained before anyone reports on them.
- It runs from the command line with open-source dbt Core, or on the dbt platform, the hosted service formerly called dbt Cloud.

## dbt data transformation services

- dbt project setup: Repository, layers, naming and environments agreed and built.
- Migration to dbt: Stored procedures and SQL scripts rebuilt as tested models.
- Tests and data quality: Data tests, unit tests, contracts and source freshness.
- Documentation: Model and column descriptions, lineage and dbt Catalog.
- CI and deployment: Changed models built and tested on every pull request.
- Semantic Layer: Metrics defined once and queried from BI and AI tools.
- dbt platform setup: Environments, jobs, Studio IDE and access on the hosted platform.
- Upgrades: Projects moved to current dbt versions in tested steps.

## Where should our dbt work start?

Most teams begin with transformations spread across scripts and schedulers. Three common paths from there.

Today: SQL scripts, stored procedures and scheduled jobs

- dbt in your repository, Start in code: Models, tests and docs in Git, run from the command line with the dbt VS Code extension for development. Best for one team on one warehouse.
- The dbt platform, Use the hosted platform: Scheduled jobs, CI, hosted documentation, Studio IDE and the Semantic Layer in one place. Best when several developers and teams share the project.
- A current dbt version, Upgrade an existing project: Deprecated features removed and the project checked against the newer v2 parser before any move. Best when you already run dbt on v1.

## What do dbt consulting services include?

From a first project to a platform several teams build on.

- dbt project setup: Repository, layers, naming and environments agreed and built.
  - Staging, intermediate and mart layers
  - Naming and style guide
  - Development and production targets
- Migration to dbt: Stored procedures and SQL scripts rebuilt as tested models.
  - Old outputs compared row for row
  - Dependencies made explicit
  - Old jobs retired one by one
- Tests and data quality: Checks that run with every build.
  - Data tests on keys and values
  - Unit tests on tricky logic
  - Contracts and source freshness
- Documentation: Descriptions and lineage people can read.
  - Model and column descriptions
  - Owners and exposures
  - dbt Catalog or generated docs
- CI and deployment: Every change built and tested before merge.
  - CI on pull requests
  - Production jobs and alerts
  - Linting and review rules
- Semantic Layer: Metrics defined once for every tool.
  - Semantic models and metrics
  - BI and spreadsheet access
  - AI tools through the dbt MCP server
- dbt platform setup: The hosted platform configured for your teams.
  - Environments and jobs
  - Studio IDE and access
  - Git provider connected
- Upgrades: Projects moved to current versions.
  - Deprecations fixed
  - Packages updated
  - Results compared before and after

## How should a dbt project be organized?

The layout we use as a starting point. Each layer has one job, so a model is easy to find and its tests are easy to read.

- models/staging/
  - One model per source table: Renamed, typed and lightly cleaned. Sources declared with freshness checks.
- models/intermediate/
  - Joins and business logic: Reusable steps that marts build on.
- models/marts/
  - Tables people report on: Customers, orders and revenue, grouped by team.
  - Semantic models and metrics: Definitions for the Semantic Layer.
- tests/ and macros/
  - Custom tests: Checks the generic tests do not cover.
  - Macros: Shared SQL written once.
- snapshots/ and seeds/
  - Snapshots: History kept for records that change in place.
  - Seeds: Small reference lists kept in Git.

## What runs when someone opens a dbt pull request?

CI builds only the models that changed and everything downstream of them, in a temporary schema, and defers the rest to production.

- Changed models and their children built
- unique and not_null tests on primary keys
- Unit tests on the revenue logic
- Model contract on the orders mart
- Relationships test, orders to customers
- Column removed that a dashboard uses (human review)

- Blocks the merge: A failed build or test stops the pull request until it is fixed.
- Isolated schema: CI writes to its own schema, so production tables are untouched.
- Platform or pipeline: Run as a dbt platform CI job, or from GitHub Actions or another CI tool.

## Which data platforms does dbt run on?

dbt runs inside your warehouse, using its compute. We set up the adapter and the environments for the platform you already have.

- Snowflake: Models built as tables, views, incremental tables or dynamic tables.
- Databricks: Models built as Delta tables governed by Unity Catalog.
- BigQuery: Partitioned and clustered tables for large event data.
- Postgres: Smaller warehouses and application databases, on dbt v1.
- GitHub: The project, pull requests and CI checks.
- Salesforce data: CRM data modeled in the warehouse for reports and Data 360.

## What is the dbt Semantic Layer?

Metrics defined once in the dbt project, powered by MetricFlow, and queried by BI tools, spreadsheets and AI tools. It needs a Starter or Enterprise tier account on the dbt platform.

- Defined in the project: Semantic models describe entities, dimensions and measures on mart models.
- Compiled at query time: MetricFlow writes the SQL and joins for each metric request.
- Same number everywhere: Every tool asks for the metric by name, so definitions cannot drift.

Relationships: Mart models to Semantic models; Semantic models to Entities; Semantic models to Dimensions; Semantic models to Metrics; Metrics to MetricFlow; MetricFlow to BI and spreadsheets; MetricFlow to AI tools via MCP.

## How does a dbt engagement run?

Three stages. The written proposal states the scope and milestones before anything starts.

- Foundation, A project the team can build on.
  - Current SQL and jobs reviewed
  - Layers, naming and environments agreed
  - First domain modeled and tested
  - CI on pull requests
- Expand, More domains, same standards.
  - Old scripts migrated and compared
  - Documentation and owners
  - Semantic Layer metrics, if in scope
- Run, Your team owns the project.
  - Production jobs and alerts
  - Review guide and training
  - Monthly plan, if you want one

## Cost and timing

The first step is a free 60-minute architecture review of your dbt and data transformation setup, with a written plan you keep. Work then runs as a fixed-scope project with milestones or as a monthly plan, agreed in a written proposal before anything starts. Plans: https://synconai.com/pricing

## FAQ

### What is dbt data transformation?

Building warehouse transformations as a dbt project: SQL models in layers, tests, sources, documentation and CI on every pull request, with shared metrics in the Semantic Layer.

### Do you offer dbt consulting services?

Yes. Our engineers set up, migrate and extend dbt projects as a fixed-scope project or on a monthly plan. SynconAI is an independent consulting firm.

### Can we hire dbt developers through you?

Yes. Our analytics engineers can join your team for a migration or a new domain, working in your repository and to your standards.

### What happened to dbt Cloud?

dbt Labs now calls its hosted product the dbt platform. It includes scheduled jobs, CI, hosted documentation, the Studio IDE, dbt Catalog and the Semantic Layer.

### Is dbt Core still open source?

Yes. dbt Core is open source under the Apache 2.0 license. dbt v1 is the original Python-based generation and v2 is the newer Rust-based one.

### Which warehouses does dbt support?

Snowflake, Databricks, BigQuery and Redshift are generally available on dbt v2. Postgres runs on dbt v1. We check adapter support for your platform first.

### What tests can dbt run?

Data tests such as unique, not_null, accepted_values and relationships, custom tests, unit tests on model logic, model contracts and source freshness checks.

### Do we need the dbt platform for the Semantic Layer?

Yes. Defining and querying Semantic Layer metrics needs a Starter or Enterprise tier dbt platform account. Models, tests and docs work without it.

## Where we work

dbt data transformation for organizations across the United States and Australia, and worldwide. Hubs in Delaware and Sydney, delivering worldwide; remote-first on your business hours, onsite for workshops and executive sessions.

## Related

- Snowflake data engineering: https://synconai.com/snowflake-consulting
- Databricks data and AI engineering: https://synconai.com/databricks-consulting
- Power BI reporting: https://synconai.com/power-bi-consulting
- DevOps consulting: https://synconai.com/devops-consulting

## Cite

When citing SynconAI dbt data transformation, link https://synconai.com/dbt-consulting or https://synconai.com/dbt-consulting.md.
