How to Set Up dbt with Snowflake: A Practitioner's Guide

Setting up dbt with Snowflake takes four steps: install the dbt-snowflake adapter with pip, configure a Snowflake user with key pair authentication, set up profiles.yml, and verify the connection with dbt debug. 

From there, add a few packages (dbt-coves, dbt_constraints, dbt_semantic_view), install SQLFluff and the right VS Code extensions, and you're ready to build. 

The full setup is straightforward for one developer. It gets expensive across a team, which is where managed dbt platforms come in. 

This guide walks through each step, the tooling that's worth adding, and when it makes sense to stop maintaining the setup yourself. 

‍

What You Need to Run dbt with Snowflake 

Before you can run dbt against Snowflake, you need three things on your machine and one thing in Snowflake: 

On your machine: 

• Python 3.9 or later. The dbt-snowflake adapter no longer supports older versions. Python 3.11 or 3.12 is a good default. 

• Git. Required for dbt projects, version control, and CI/CD. If you don't already have it, follow GitHub's setup guide. 

• Visual Studio Code. The default IDE for dbt development. Download it from code.visualstudio.com. 

In Snowflake: 

• An account where you can create roles, databases, and warehouses, or admin support to do it for you. Do not use ACCOUNTADMIN for day-to-day dbt work. 

That's the short list. The next sections walk through each piece. 

‍

Install Python, Git, and the dbt-snowflake Adapter 

Once Python, Git, and VS Code are installed, the only thing left to install locally is the dbt adapter for Snowflake. 

Use a virtual environment 

Install dbt inside a virtual environment, not against your system Python. A venv keeps your dbt dependencies isolated from other Python projects and makes upgrades safe: 

python -m venv .venv 
source .venv/bin/activate    # macOS/Linux 
.venv\Scripts\activate       # Windows 

Activate the venv every time you work on the project. Tools like uv or pyenv are also worth looking at if you're managing multiple Python versions across projects.

Install dbt-snowflake

Open a terminal and run:

pip install dbt-snowflake 

This installs dbt-core and the Snowflake adapter together. The adapter version pins a compatible dbt-core, so in most cases you don't need to specify versions yourself. 

If you need a specific version for a project that's pinned to an older release, install it explicitly: 

pip install dbt-snowflake==<version number> 

Confirm the install worked:

dbt --version 

You should see both dbt-core and dbt-snowflake listed.

Configure Your Snowflake Account for dbt  

Before dbt can connect to Snowflake, you need a Snowflake user with the right permissions, a role for that user to assume, a database where dbt can build models, and a warehouse for dbt to use as compute. You also need an authentication method. As of late 2025, that means key pair authentication, not a password. 

Create the Role, Database, and Warehouse  

For a typical dbt setup, create a dedicated role, database, and warehouse rather than reusing existing ones. This keeps dbt's footprint isolated and easy to govern. 

Run the following as a user with SECURITYADMIN privileges (or higher, but avoid ACCOUNTADMIN for day-to-day work): 

-- Create a warehouse for dbt compute 
create warehouse transforming 
  warehouse_size = 'xsmall' 
  auto_suspend = 60 
  auto_resume = true 
  initially_suspended = true; 
 
-- Create a database where dbt will build models in development 
create database analytics_dev; 
 
-- Create a role for dbt developers 
create role analyst; 
 
-- Grant ownership of the dev database to the role 
grant ownership on database analytics_dev to role analyst; 
 
-- Grant warehouse usage to the role 
grant usage on warehouse transforming to role analyst; 
 
-- Grant the role to your user 
grant role analyst to user your_username; 

When dbt runs, it creates a schema for each developer inside analytics_dev and uses the transforming warehouse for compute. Production deployments typically use a separate role, database, and warehouse, governed through CI/CD rather than developer accounts. 

For a more comprehensive Snowflake permission model (read-only roles, environment-specific access, masking policies, RBAC at scale), see How to Configure Snowflake for dbt on the dbt blog. We'll also cover infrastructure-as-code options for managing this further down. 

Set Up Key Pair Authentication 

Key pair authentication is the correct default for connecting dbt to Snowflake. As of November 2025, Snowflake enforces MFA on username/password logins, which makes password authentication unworkable for any unattended dbt run. 

Step 1. Generate a key pair on your machine.

# Generate an unencrypted private key 
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -nocrypt 
 
# Generate the matching public key 
openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub 

Windows users: install OpenSSL via Git for Windows (which bundles it). 

For production or CI/CD environments, store the private key in a secrets manager rather than on developer machines. 

Step 2. Register the public key with your Snowflake user. 

In Snowflake, run:

alter user your_username set rsa_public_key='<paste the contents of rsa_key.pub here, without the BEGIN/END lines>'; 

Step 3. Reference the private key from profiles.yml.

dbt supports either a path to the private key file or the key contents inline. We'll set this up in the next section. 

For SSO environments where browser-based authentication is acceptable for local development, externalbrowser is also supported, but it can't be used for unattended runs. For most teams, key pair auth is the consistent answer across local development, CI, and production.

‍

Configure dbt and Verify the Snowflake Connection 

With Snowflake configured, the next step is to point dbt at it. dbt reads connection details from a file called profiles.yml, which lives in your home directory at ~/.dbt/profiles.yml. Project-level Snowflake behavior (table types, query tags, warehouse overrides) lives in dbt_project.yml inside the project itself. 

Initialize the Project with dbt init

If you're starting from scratch, dbt init creates a new project and prompts you for connection details:

dbt init my_project 

If you're cloning an existing project, run dbt init from inside the cloned repo to set up your profiles.yml entry without overwriting the project files. 

The init flow asks for the database type, account identifier, user, authentication method, role, database, warehouse, schema, and threads. The result is a working profiles.yml entry that looks like this: 

my_project: 
  target: dev 
  outputs: 
    dev: 
      type: snowflake 
      account: abc12345.us-east-1 
      user: your_username 
      private_key_path: /Users/your_username/.snowflake/rsa_key.p8 
      role: analyst 
      database: analytics_dev 
      warehouse: transforming 
      schema: dbt_your_username 
      threads: 8 

A few notes: 

• The account value uses the preferred <orgname>-<account_name> format. See Snowflake's account identifier documentation for how to look up your organization name and account name in Snowsight.  

• private_key_path points to wherever you saved the private key you generated. Use the absolute path. The ~/ shorthand isn't always reliable in profiles.yml. 

• schema is the developer's personal schema. The convention dbt_<username> prevents developers from stepping on each other. 

• threads controls how many models dbt builds in parallel. 8 is a reasonable starting point. 

If you maintain a project that other developers will clone, add a profile_template.yml at the project root. It pre-fills the fixed values (account, role, database, warehouse) and only prompts each developer for what's truly user-specific (their username, schema, threads). This saves real time across a team. 

Run dbt debug to Verify the Connection  

Before doing anything else, confirm dbt can connect to Snowflake:

dbt debug 

If everything is configured correctly, you'll see All checks passed! at the bottom of the output. If you get an error, the most common causes are: 

• Wrong account identifier format (Snowflake account IDs vary by region and cloud). 

• Public key not registered against the user, or registered with the BEGIN/END lines included. 

• Role missing USAGE on the warehouse or OWNERSHIP on the database. 

• Wrong private key path, or the key file has restrictive permissions Python can't read. 

If you're stuck, the #db-snowflake channel on the dbt Community Slack is the fastest way to get unstuck. 

Useful profiles.yml Settings to Know

dbt init gives you a working baseline, but a few profiles.yml settings are worth knowing about once you start running dbt regularly: 

• reuse_connections: true keeps Snowflake connections alive across queries, which speeds up runs noticeably and is especially helpful with SSO. 

• client_session_keep_alive: true prevents Snowflake from timing out long sessions during big builds. 

• query_tag sets a default tag on every query dbt issues. This makes it easy to filter dbt activity in QUERY_HISTORY (we'll cover model-level overrides in the next section). 

• connect_retries and connect_timeout are worth tuning if you hit transient connection failures. 

Full reference: dbt-snowflake profile configuration. 

Useful dbt_project.yml Settings for Snowflake

Where profiles.yml controls how dbt connects, dbt_project.yml controls how dbt builds against Snowflake. A few Snowflake-specific configs are worth knowing about: 

Transient tables. Snowflake transient tables skip Fail-safe storage, which reduces cost. dbt creates transient tables by default. To make a folder of models permanent (for example, models that need Time Travel beyond one day or Fail-safe protection): 

models: 
  my_project: 
    marts: 
      +transient: false 

Query tags at the model level. Set a default in profiles.yml and override per model or folder in dbt_project.yml: 

models: 
  my_project: 
    finance: 
      +query_tag: "finance_models" 

Copy grants on rebuild. When dbt rebuilds a table, grants on the previous table are dropped by default. To preserve them:

models: 
  my_project: 
    +copy_grants: true 

Warehouse override. Most models can run on a small warehouse, but a few heavy ones may need more compute. Override per model or folder rather than running everything on a large warehouse:

models: 
  my_project: 
    heavy_marts: 
      +snowflake_warehouse: "transforming_xl" 

This also works for tests, which is useful when you want lightweight tests on a smaller warehouse than your model builds. 

The full list of Snowflake-specific configs lives in the dbt Snowflake configurations reference. 

‍

dbt Packages and Python Libraries Worth Adding

dbt is most useful when paired with the right packages and Python libraries. The list below isn't exhaustive, but each of these earns its place in a serious dbt-on-Snowflake project. 

dbt-coves (Datacoves)

dbt-coves is an open-source CLI tool maintained by Datacoves. It automates the tedious parts of dbt development that nobody enjoys doing by hand: generating source definitions, staging models, property files, and Airflow DAGs from your warehouse metadata. 

Install it with pip:

pip install dbt-coves 

Most teams use it for staging model generation. Point it at a source schema and it produces clean staging models, source YAML, and the matching property files in seconds. For analytics engineers who model dozens of source tables, this saves hours per project. 

dbt-coves also includes utilities for backing up Airbyte and Fivetran configurations, which is useful when you want your ingestion config to live in Git alongside your dbt models. 

dbt_constraints (Snowflake Labs)

dbt_constraints is a Snowflake Labs package that turns your existing dbt tests into actual database constraints. If you've already added unique, not_null, and relationships tests, this package will generate matching primary key, unique key, foreign key, and not-null constraints on Snowflake automatically. 

Add it to packages.yml: 

packages: 
  - package: Snowflake-Labs/dbt_constraints 
    version: [">=1.0.0", "<2.0.0"] 

Why bother, given that Snowflake doesn't enforce most constraints? 

• Query performance. Snowflake's optimizer uses primary key, unique key, and foreign key constraints during query rewrite when they're set to RELY. dbt_constraints creates constraints with RELY automatically when the underlying test passes, and NORELY when it fails. The optimizer can use this for join elimination, which removes unnecessary tables from query plans. 

• Data modeling tools. BI and modeling tools like DBeaver and Oracle SQL Developer Data Modeler can reverse-engineer accurate data model diagrams when constraints exist. Without constraints, those diagrams are guesswork. 

• Documentation that's always in sync. The constraints in your warehouse match what dbt actually tests. There's no drift between "what the tests say" and "what the database knows." 

dbt_semantic_view (Snowflake Labs)

dbt_semantic_view is a newer Snowflake Labs package that adds a semantic_view materialization to dbt. It lets you define and version-control Snowflake's native semantic views the same way you manage models. 

Add it to packages.yml:

packages: 
  - package: Snowflake-Labs/dbt_semantic_view 
    version: [">=1.0.0", "<2.0.0"] 

A semantic view model looks like this:

{{ config(materialized='semantic_view') }} 
 
TABLES ( 
  orders AS {{ ref('fct_orders') }}, 
  customers AS {{ ref('dim_customers') }} 
) 
 
RELATIONSHIPS ( 
  orders_to_customers AS orders (customer_id) REFERENCES customers (customer_id) 
) 
 
DIMENSIONS ( 
  customers.region AS region, 
  orders.order_date AS order_date 
) 
 
METRICS ( 
  orders.total_revenue AS SUM(orders.amount), 
  orders.order_count AS COUNT(orders.order_id) 
) 

Once materialized, the semantic view is a real Snowflake object. It can be consumed by Cortex Analyst, Snowflake Intelligence, and any tool that queries Snowflake. Because the definition lives in your dbt project, metric logic gets the same Git history, peer review, and CI/CD as your transformations. 

This matters more than it sounds. Most semantic layers either live outside dbt (drift inevitable) or get reinvented in every BI tool (drift guaranteed). Defining the semantic layer in dbt and materializing it natively in Snowflake closes that gap. 

SQLFluff

SQLFluff is the de facto SQL linter for dbt. It enforces formatting and style rules across your project so reviewers can focus on logic, not whether someone used trailing commas or capitalized SQL keywords. 

Install it alongside dbt: 

pip install sqlfluff sqlfluff-templater-dbt 

The sqlfluff-templater-dbt plugin lets SQLFluff understand Jinja, refs, sources, and macros. Without it, the linter chokes on dbt syntax. Configure rules in a .sqlfluff file at the project root, and add a dbt_project.yml reference so the templater can find your project. 

Datacoves sponsors SQLFluff as part of its commitment to open-source dbt tooling. 

dbt-checkpoint (Datacoves)

dbt-checkpoint is a set of pre-commit hooks that validate dbt project quality before code is merged. It catches the things code review usually misses: a model without a description, a column that's documented in YAML but missing from the SQL, a source that's been added without tests. 

Install it as part of your pre-commit setup: 

pip install pre-commit 

Then add the dbt-checkpoint hooks to .pre-commit-config.yaml:

repos: 
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint 
    rev: v2.0.7 # Verify the latest released version of dbt-checkpoint  
    hooks: 
  	- id: check-model-has-description 
  	- id: check-model-columns-have-desc 
  	- id: check-model-has-tests 
  	- id: check-source-has-freshness 
  	- id: check-script-has-no-table-name 

Run pre-commit install once and the hooks fire automatically on every commit. 

The point isn't to enforce every possible rule. It's to keep technical debt from accumulating before it has a chance to compound. Datacoves maintains dbt-checkpoint as part of the broader dbt ecosystem. 

For a broader look at testing strategy, see An Overview of Testing Options for dbt. 

‍

VS Code Extensions That Make dbt on Snowflake Easier

VS Code is the default IDE for dbt development. A few extensions turn it from "a nice editor" into a productive dbt workspace. 

Snowflake VS Code Extension

The official Snowflake extension brings the Snowsight experience into VS Code. You can browse databases, run worksheets, view query results, and upload or download files from Snowflake stages, all without leaving the editor. 

For dbt developers, the most useful part is being able to run ad-hoc queries against your warehouse next to the model you're working on. No more flipping between the browser and your IDE every time you need to inspect a column or check a row count. 

Power User for dbt (aka. dbt Power User)

Power User for dbt (formerly called dbt Power User) is the most useful dbt extension. It adds the things dbt should arguably ship with itself: 

• Run a model, test, or full DAG with a click instead of typing the command. 

• Preview the result of a model or any selected CTE inline. (contributed by Datacoves) 

• Click through ref() and source() calls to jump to the underlying file. 

• See the compiled SQL side-by-side with the Jinja source. (contributed by Datacoves) 

• Visualize the lineage graph from a model. 

If you only install one extension, install this one. 

SQLFluff Extension

The SQLFluff VS Code extension wires the SQLFluff linter directly into the editor. Linting errors show up inline as you type, with hover descriptions that link to the SQLFluff docs. 

This is the difference between linting being a chore developers run occasionally and linting being something they fix as they write. The former gets ignored. The latter keeps the codebase clean. 

The extension reads from the same .sqlfluff config file that the CLI uses, so there's no duplicate setup. 

‍

Bringing AI Into Your dbt on Snowflake Workflow 

A modern dbt-on-Snowflake AI workflow combines an in-IDE assistant (Power User for dbt, GitHub Copilot, Claude Code) with a Snowflake-native assistant (Snowflake Cortex CLI) and MCP servers that give the AI structured access to your dbt project and warehouse metadata. 

AI has moved past being a novelty in dbt development. Used well, it accelerates the work that doesn't need a human (writing tests, generating documentation, drafting models, explaining errors) and gives developers more time for the work that does (modeling decisions, business logic, architecture). 

A modern dbt-on-Snowflake workflow has a few good options. 

Snowflake Cortex CLI (CoCo). Snowflake's command-line AI assistant runs against your Snowflake account and works like Claude Code or other terminal-based coding assistants. It's particularly useful for dbt because it can find tables and columns, inspect schemas, and generate SQL grounded in your actual warehouse, not a generic LLM guess. 

Read more: Datacoves Expands Snowflake AI Data Cloud Support. 

Claude Code, GitHub Copilot, OpenAI Codex CLI, Gemini CLI. Each of these works inside VS Code or the terminal. Claude Code and Codex CLI are particularly strong for multi-step refactors across a dbt project. Copilot is hard to beat for inline suggestions. The right choice depends on what your organization already pays for and what data your security team is comfortable sending to which provider. 

MCP servers. Model Context Protocol servers let AI assistants interact with dbt projects, Snowflake, and other tools through a standardized interface. Snowflake and the broader community have shipped MCP servers. Pairing an MCP server with an AI assistant gives the model real awareness of warehouse metadata. 

The thing to avoid is treating AI as a separate workflow. The point is to integrate it into the same VS Code environment where developers already work, with credentials and access already configured. Asking developers to copy-paste between a chat window and their IDE is friction the team will route around within a week. 

This is one of the harder parts of running dbt on Snowflake at scale: keeping AI tooling consistent across developers, with the right credentials, the right MCP servers, and the right governance around what data the AI can see. Datacoves comes preconfigured with Claude Code, Snowflake Cortex CLI, GitHub Copilot, OpenAI Codex CLI, and Gemini CLI inside the in-browser VS Code environment, all working against your Snowflake account with no per-developer setup. For teams that want to standardize how AI shows up in dbt development, that's a meaningful head start. 

‍

Managing Snowflake Infrastructure Alongside dbt

dbt manages objects inside Snowflake (tables, views, tests, documentation). It does not manage Snowflake itself. Roles, users, grants, warehouses, masking policies, and resource monitors live outside dbt's scope and need a separate infrastructure-as-code tool. 

Snowflake roles, users, grants, warehouses, masking policies, row access policies, network policies, resource monitors, and databases all live outside dbt's scope. Most teams handle this with whatever combination of click-ops, Snowsight, and SQL scripts has accumulated over the years. That works until it doesn't. 

The point at which it stops working is usually predictable: 

• A new analyst joins and needs the right access. Nobody can fully reconstruct what the previous analyst was granted. 

• A masking policy needs to be applied consistently across thirty tables containing PII. Someone misses three of them. 

• An audit asks who has OWNERSHIP on production schemas. The answer takes a week to assemble. 

• A new environment (dev, QA, staging) needs to mirror production. The clone drifts within a sprint because grants are applied manually. 

The fix is to manage Snowflake infrastructure as code, the same way you manage dbt models. Define roles, grants, warehouses, and policies in version-controlled files. Apply changes through pull requests. Let CI/CD enforce that production matches what's in Git. 

Why Terraform isn't a great fit for Snowflake

Terraform is the obvious starting point, but it's the wrong tool for most Snowflake teams. Terraform was built for managing infrastructure across many cloud providers, with a state file as its source of truth. For Snowflake specifically, this creates real problems: 

• The state file becomes a sync target instead of a record of intent. Drift between Snowflake and the state file happens often, and resolving it is painful. 

• The Terraform DSL is unfamiliar territory for analytics engineers. Most data teams don't have full-time platform engineers who already speak Terraform. 

• Snowflake-specific features (RBAC at scale, tag-based masking policies, row access policies) require contortions in Terraform that a Snowflake-native tool can express directly. 

Snowcap: Snowflake-native infrastructure as code

Snowcap is the Snowflake-native IaC tool Datacoves built and maintains as open source. It manages users, roles, grants, warehouses, masking policies, row access policies, and over 60 other Snowflake resource types using YAML or Python configuration. No state file. No DSL to learn. No abstraction layer between your config and Snowflake. 

Snowcap is opinionated where opinion matters most: 

• RBAC at scale. Define role hierarchies and grants in YAML. Apply consistently across teams, projects, and environments. 

• Tag-based masking policies. Tag a column once, apply a masking policy to every column with that tag automatically. 

• Row access policies. Define them once, version them in Git, deploy them like any other Snowflake object. 

• CI/CD-first. Every change is a pull request. Production state matches what's been merged. 

If dbt is the workshop where you build data products, Snowcap is the power tools that keep the workshop itself in good order. The two work side by side: Snowcap manages who can see what and where compute lives, dbt manages how the data gets transformed. 

For teams already running dbt with Snowflake, adding Snowcap is one of the highest-leverage moves available. It doesn't replace anything you have. It fills the gap that almost every dbt team has but pretends not to: governed, version-controlled, repeatable Snowflake infrastructure. 

‍

When to Stop DIY and Move to Managed dbt

The setup in this guide works. Plenty of teams run it successfully. The honest question isn't whether you can do it yourself. It's whether you should, given what your team is trying to accomplish. 

Here's the pattern most data teams follow: 

At one or two developers, DIY is the right call. The setup is straightforward, the maintenance is low, and the team can iterate on conventions as they go. There's no good reason to add a managed platform at this stage. 

At three to five developers, the cracks start to show. Onboarding a new developer takes a week instead of a day because everyone's local environment is slightly different. Python versions drift. Someone's profiles.yml has a passphrase from 2024 that nobody can find. CI/CD is held together by a YAML file one engineer maintains. It still works, but real time is being lost to platform maintenance. 

At ten or more developers, DIY is expensive. Onboarding tax compounds. Upgrades require coordinating across the whole team. Secrets management becomes a real problem. Multiple dbt projects need governed dependencies. Production runs need an actual orchestrator, not a cron job. CI/CD pipelines need ownership. Someone is now spending a meaningful chunk of their week on platform work that has nothing to do with delivering data products. 

For regulated industries, DIY runs into a different wall. Pharma, healthcare, financial services, and government workloads usually require private cloud deployment, strict identity controls, audit logging, and architectures that pass internal security review. SaaS dbt platforms are often a non-starter. DIY on Kubernetes is doable, but it pulls in months of platform engineering work before the data team writes a single model. 

The decision isn't really between "DIY" and "managed." It's between who builds and maintains the platform layer. Either your team does it, or someone else does. If platform engineering is your team's competitive advantage, build it yourself. If your team's competitive advantage is delivering data products, the platform layer is overhead. 

See also: dbt Deployment Options. 

What managed dbt solves

Managed dbt platforms (the category, not the marketing) handle the layer between dbt and the rest of your infrastructure. The good ones cover: 

• A consistent in-browser or pre-configured VS Code environment, so every developer is on the same Python version, the same dbt version, and the same set of extensions from day one. 

• Managed Airflow for orchestration, both a personal sandbox for development and a shared production environment. 

• Pre-built CI/CD pipelines for dbt tests, SQL linting, governance checks, documentation, and deployment. 

• Secrets management integrated with your existing vault. 

• Private cloud deployment for teams that need data to stay inside their own network. 

• Best-practice templates so new projects start with the right structure instead of inventing it. 

Datacoves is the managed dbt platform we build, and the Snowflake integration is one of our most common deployments. Teams running dbt on Snowflake get an end-to-end environment in their own cloud: managed dbt, managed Airflow, in-browser VS Code, CI/CD, governance, and AI tooling, all preconfigured and connected to their Snowflake account. 

For a side-by-side look at the trade-offs, see our comparison of dbt Core vs dbt Cloud. 

‍

Final Thoughts

dbt and Snowflake is one of the most productive combinations in modern data engineering. The tools fit together, the community is active, and the path from "first model" to "production analytics" is well-trodden. That doesn't mean the path is short. 

The setup itself isn't the hard part. Installing the adapter, configuring authentication, writing profiles.yml, running dbt debug, this is a one-afternoon exercise. The harder part is everything that comes after: keeping ten developers on the same Python version, governing who can do what in Snowflake, integrating AI without creating a mess, deciding which packages are worth their weight, and making the whole thing maintainable as the team grows. 

The tooling in this guide handles most of it. dbt-coves removes the boilerplate. dbt_constraints turns your tests into actual database constraints. dbt_semantic_view brings the semantic layer into your dbt project. SQLFluff and dbt-checkpoint keep code quality from drifting. Power User for dbt makes daily development faster. Snowcap fills the gap dbt was never meant to fill. 

Where it gets expensive is at scale. The setup that works for two developers doesn't scale to twenty without serious investment in the platform layer underneath. Either your team builds and maintains that layer, or you find a managed platform that does it for you. There's no third option that holds up over time. 

If you're running dbt on Snowflake today and the setup is starting to feel heavier than it should, book a free architecture review. We'll discuss your environment, show you where Datacoves fits, and tell you honestly whether it makes sense for where you are.