How dbt connects to your data platform

A guide to every connection model, from dbt Core to single-tenant enterprise. Click any component to learn more.

dbt Core is free software your team installs and runs on your own computers or servers. dbt Labs writes the software, but once you download it, your team controls everything, including how it connects to your database.

Simple version: dbt Core is like a recipe app you install on your own phone. The app developer does not control your Wi-Fi or what restaurant you order from. You own all of that.

Getting help

No paid support from dbt Labs. Help comes from the dbt community through Slack, GitHub, and public documentation. Your team is responsible for keeping it running.

Managed by dbt

Nothing

Internet traversal

Depends on host

Connectivity

Fully customer-controlled

Support

Community only

Click any component to learn more.

Setup and support

Setup

Configure profiles.yml with warehouse credentials. Network path depends on where Core runs. No dbt-managed infrastructure in the path.

Support

Community only. dbt Slack, GitHub Issues, docs.getdbt.com. No SLA. Your team owns the full stack.

Key point: dbt Labs manages nothing in the connection path. Run it in a private subnet and the connection stays private. Run it on a laptop and it goes over the internet. Full flexibility, full responsibility.

The dbt Platform is a hosted service run by dbt Labs. Your team logs in, sets up your data work, and dbt Labs handles the servers. You share that infrastructure with other dbt customers, like sharing a building with other companies, each in their own locked office.

Is this secure? Yes, for most companies. The connection is encrypted and your database still requires a login. Some industries (banking, healthcare) may require a fully private connection that never touches the internet. See the "Private connections" tab for that.

Getting help

dbt Labs support handles platform questions. Your IT team manages the firewall rules. If dbt changes their server addresses, they notify you and your team updates the firewall.

Internet traversal

Yes (default)

Setup complexity

Low

IP allowlisting

Required

Dedicated compute

No, shared

Click any component to learn more.

Setup and support

Setup

Add warehouse credentials in the UI and allowlist dbt's NAT IPs in your firewall. Lowest setup effort of any model.

Support

dbt Labs support handles the platform. Your team manages firewall allowlist updates when NAT IPs change.

Multi-tenant is where most teams start. The tradeoff is shared compute (logically isolated) and a default connection over the public internet. Add PrivateLink to get private connectivity without changing your deployment tier.

Same dbt Platform, but your company gets its own private copy. Only your company's work runs on it. This is common in banking, insurance, and healthcare, where rules may require that systems are not shared with other organizations.

Do I need this? Not always. Most companies do fine with the shared service. Single-tenant is typically chosen when a compliance or legal team specifically requires it, or when your security team wants a simpler story for an audit or leadership review.

Getting help

dbt Labs provides a dedicated support tier and an account team. They are typically involved from the beginning of setup.

Internet traversal

Optional

Dedicated AWS account

Yes

IP allowlisting

No (with PL)

Setup complexity

Medium

Click any component to learn more.

Setup and support

Setup

Same steps as multi-tenant, with a stable dedicated account. Your security team can validate the exact AWS account ID before accepting any connection.

Support

Dedicated support tier. Account team and field engineering are typically involved from the start.

Single-tenant vs multi-tenant: The runtime lives in a dedicated AWS account with no shared compute. Compliance conversations are simpler and CIDR ranges are predictable.

A private connection means data never travels over the public internet at all. Instead it goes through a locked private tunnel between dbt and your database. Select an option below to see how each one works.

Least setup

Your database handles it

Your database tool already has a private connection option built in. You just turn it on.

Shared setup

dbt builds their side

dbt Labs sets up the tunnel on their end and sends a request. Your team approves it.

Most control

Your team builds the tunnel

Your infrastructure team builds the private tunnel entry point. Most setup, most control.

Which one should we use? Start with your database's built-in option if it supports private connections. If you need more control over who can connect, or your database does not support it, ask your dbt account team which option fits your setup.

Getting help

All three options keep data off the public internet. The difference is who builds each side of the tunnel. dbt's field engineering team can guide your setup for any of these options.

Internet traversal

None

Public IPs needed

IP allowlisting

Not needed

CISO friendliness

High

Lowest lift

Warehouse-native PrivateLink

Snowflake, Databricks, etc. expose a PrivateLink endpoint directly. dbt connects to the private hostname instead of the public one. No NLB or endpoint service needed on your side.

Shared setup

dbt-managed PrivateLink

dbt Labs provisions the consumer VPC endpoint and initiates the connection to your endpoint service. Your team provisions the endpoint service and NLB, then approves the connection request.

Most control

Customer-managed PrivateLink

Your team provisions the VPC endpoint service and internal NLB. You share the service name with dbt Labs. You control the account ID allowlist and can revoke access at any time.

Click any component in the diagram to learn more.

Setup and support

Warehouse-native

Enable PrivateLink on your warehouse account and update the connection hostname in dbt. Lowest setup effort.

dbt-managed

dbt Labs provisions the consumer endpoint. Your team provisions the endpoint service and NLB, then approves the connection request from dbt's account ID.

Customer-managed

Your team provisions the endpoint service and NLB. Share the service name with dbt Labs. Field engineering guides enterprise setups. One-time setup with a documented runbook.

All three share the same guarantee: traffic stays on the AWS backbone and never touches the public internet. The difference is who builds which side of the connection and how much control your team retains.

Here is a simple way to pick the right option.

Building it yourself or want full control? Use dbt Core. Free, open-source, your team manages everything.

Want dbt Labs to manage the servers? Start with the shared dbt Platform. Works out of the box for most companies.

In a regulated industry or need a dedicated instance? Ask about single-tenant. Same service, but yours alone.

Security team says data cannot go over the internet? Add a private connection. See the private connections tab for the three setup options.

All connection modes compared

	dbt Core	Multi-tenant	Single-tenant	+ PrivateLink	+ VPC peering
Internet traversal	Depends on host	Yes	Yes (default)	None	None
Managed infra	None, self-managed	dbt Labs (shared)	dbt Labs (dedicated)	Split, see tab	Split, both sides
Warehouse endpoint	Your choice	Public required	Public required	Private only	Private only
IP allowlisting	Your call	Required, dbt NAT IPs	Required, stable IPs	Not needed	Security groups
Dedicated compute	Your infra	No, shared	Yes	Inherits from tier	Inherits from tier
Cloud provider	Any	AWS	AWS	AWS only	AWS, GCP (caveats)
Same region required	No	No	No	No, cross-region OK	Yes
Setup complexity	Low	Low	Low	Medium	High
Support	Community only	dbt Labs support	Dedicated tier	Field engineering for setup	Field eng, more coordination
CISO friendliness	Depends on setup	Moderate	Moderate+	High	Moderate
Best for	OSS-first, custom orchestration	Getting started on platform	Regulated industries	Strict private connectivity on AWS	GCP or bidirectional needs

How to choose

Start with dbt Core if you want full control or are evaluating before committing to the platform.

Start with multi-tenant if you want dbt Labs to manage the runtime. Add PrivateLink before production if your security team requires private connectivity.

Choose single-tenant if you need dedicated infrastructure or are in a regulated industry.

Add PrivateLink when your warehouse cannot have a public endpoint or your CISO requires all traffic off the internet. Start with warehouse-native if your warehouse supports it.

Use VPC peering only if PrivateLink is not available for your architecture or you need bidirectional VPC connectivity.