Manage warehouse compute

Overview

Hightouch runs directly in your warehouse. When you build audiences, run syncs, calculate traits, or execute journeys in Hightouch, your warehouse runs SQL queries to power those actions.

Because of this, Hightouch contributes to your warehouse compute usage.

Many customers find that Hightouch drives less than 1% of their annual consumption costs, this guide focuses on making that usage easier to plan for and manage. It explains:

• How warehouse billing typically works
• What drives compute usage in practice
• How different Hightouch workloads affect your warehouse
• How schema and model design impact performance
• Which levers you can use—in your warehouse and in Hightouch—to manage cost and governance

How warehouse billing works

Most warehouses bill for three categories of usage:

• Compute – processing power used to execute queries and data operations
• Storage – how much data is stored
• Platform / cloud services – fees for metadata, management features, and other platform services

Hightouch primarily affects compute.

Each time your warehouse runs a query—for example:

• Evaluating an audience or trait
• Computing a diff for a sync
• Running a journey step
• Writing an internal audit table

it consumes compute.

What drives warehouse compute

Compute usage typically depends on how often queries run, how much work they do, how many run at once, warehouse size, and idle time.

1. How often queries run

More frequent queries increase total compute usage. Common drivers include:

• Short-interval sync schedules
• High-volume triggered journeys
• Frequent audience recalculations or previews in Customer Studio
• Repeated exploratory queries against large models

To reduce cost, lower the frequency of background jobs and align schedules with actual business needs.

2. How much work each query does

Queries that perform large joins, heavy aggregations, or full-table scans consume more compute.

Common contributors include:

• Large joins across multiple big tables
• Deeply nested SQL
• Full-table scans on very large models
• Aggregations across long time windows in event tables

To reduce compute, run heavy joins and calculations ahead of time (for example, in dbt) and have Hightouch read from the resulting table.

3. How many queries run at the same time

Concurrency (sometimes called parallelization) refers to how many queries run at the same time.

Higher concurrency can:

• Increase load on a warehouse
• Trigger auto-scaling or multi-cluster behavior
• Increase peak credit usage

Concurrency is influenced by:

• How many syncs run at once
• How many journeys or audiences evaluate simultaneously
• Overlap between scheduled jobs and interactive use

Adjust concurrency based on what your warehouse can handle and how quickly jobs need to finish.

4. Warehouse size and scaling

Warehouse size (sometimes called a compute engine) determines how much compute is available at once.

• Larger warehouses process more data per unit time but cost more while running.
• Smaller warehouses cost less while running but may introduce wait times during spikes.

Start with a modest warehouse size and scale up only if jobs regularly take too long. Many customers begin with a Medium warehouse.

5. Idle time

Warehouses that remain running when no queries are executing still incur compute cost.

Idle behavior depends on:

• Auto-suspend (how quickly the warehouse turns off when it’s idle)
• How jobs are scheduled throughout the day
• Whether background jobs run continuously or in batches

Many environments default to ~10 minutes of inactivity. Lowering auto-suspend to around 1 minute—while keeping auto-resume enabled—is often one of the simplest ways to reduce unnecessary compute usage.

How Hightouch uses your warehouse

Hightouch workloads fall into a few broad categories. Understanding them helps you decide what needs to be fast and what can run in the background.

Interactive workloads

Interactive workloads are user-driven and show up directly in the UI:

• Audience previews in Audiences
• Trait previews in Traits
• Insights and dashboards in Intelligence
• Some AI-assisted workflows

These workloads prioritize quick load times because users expect fast responses.

Batch workloads

Batch workloads run on a schedule or in the background:

• Sync runs to downstream tools
• Identity Resolution jobs
• Large trait recalculations
• Audience snapshots and backfills

These workloads prioritize processing large volumes of data reliably and can often run on a smaller or lower-priority warehouse.

Background jobs

Some jobs run periodically but are not time-sensitive:

• Match Booster enrichment refreshes
• Cached column suggestion refreshes
• Non-urgent audience updates

Because these jobs tolerate delay, they are good candidates for:

• Lower-frequency schedules
• Smaller, dedicated warehouses
• Running during off-peak windows

Strategies to save on compute in your warehouse

Use a dedicated warehouse and user for Hightouch

Create:

1. A dedicated warehouse for Hightouch

   • Allows you to clearly see what Hightouch costs and prevents it from competing with other workloads.

2. A dedicated user (or service account) and role with access only to the data Hightouch needs

   • Makes it easier to control access and audit the queries Hightouch runs.

Starting here provides the clearest cost visibility and strongest governance controls.

Optimize warehouse settings

Most warehouses expose settings that control how they run. The exact names differ by platform, but the concepts are similar:

1. Choose the right warehouse size

   • Start with a size (often Medium) that handles busy periods without long wait times.
   • Increase size if jobs regularly run too long.
   • Decrease size if the warehouse is mostly idle.

2. Reduce idle time

   • Lower auto-suspend so the warehouse turns off soon after queries finish.
   • Around 1 minute is common.
   • Keep auto-resume enabled.

3. Set query time limits

   • Set maximum runtimes to prevent a single query from running for hours.
   • If queries hit time limits frequently, optimize them before raising the threshold.

4. Use serverless or multi-cluster options when appropriate

   • Helpful when you have steady daily usage plus occasional spikes.
   • Allows capacity to scale during busy periods without permanently running a larger warehouse.

Control how many queries run at once

Adjust how many queries your warehouse can run at the same time.

• Increasing concurrency allows more work to finish sooner but may increase peak usage.
• Decreasing concurrency smooths load but can extend total runtimes.

Adjust this setting based on whether cost spikes or missed deadlines are the bigger concern.

Use budgets and resource monitors

Most warehouses provide:

• Budgets to set monthly spending limits
• Resource monitors to track credit usage and optionally suspend warehouses at thresholds

Using these with a dedicated Hightouch warehouse makes it easier to detect unusual usage and enforce cost controls.

Turn complex queries into tables

If a model performs heavy joins or aggregations every time it runs:

• Run those joins and calculations ahead of time (for example, in dbt) and save the results as tables.
• Simplify the model Hightouch reads from.

If a simple SELECT * FROM your_model LIMIT 1 query runs slowly, the model is likely doing too much work at read time and should be refactored.

Structure your tables intentionally

There’s no single “right” way to structure your tables, but these patterns consistently help:

• Keep data normalized by default.
• Only denormalize when it clearly removes slow, repeated joins.
• Avoid denormalizing large fact tables unnecessarily, as this can increase how much data the warehouse must read.

For time-series and large tables, consider adding clustering keys (how your warehouse organizes data to make common filters faster) once you understand real query patterns.

Route different workloads to different warehouses

If your warehouse supports multiple compute engines, route:

• Interactive workloads (e.g., audience previews, dashboards, AI-powered workflows) to a warehouse tuned for fast UI queries
• Batch workloads (e.g., syncs, IDR, heavy traits)to a warehouse tuned for large scheduled jobs

This keeps the UI responsive during heavy sync windows and separates cost management for different workload types.

Strategies in Hightouch

Hightouch provides several controls in the UI to help manage warehouse compute.

Simplify the models that power your Customer Studio schema

Your schema and models directly affect how much work each query must perform.

The parent / related / event pattern organizes data into a primary table with supporting tables joined to it.

• Parent model: stable identifiers and frequently segmented attributes
• Related models: 1:many relationships such as orders or sessions

Keep joins simple at run time and avoid long chains of complex SQL.

Limit large event tables to what activation requires

Event tables can grow quickly. To keep them efficient:

• Limit time windows to what activation actually requires
• Use pre-aggregated tables for common metrics when helpful
• Organize tables based on the columns most often used in filters (for example, date or tenant)

Traits can perform aggregations directly, which may reduce the need for separate pre-aggregation tables.

Schedule background jobs at the lowest effective frequency

Many workloads do not require high-frequency updates.

• Reduce sync frequencies for enrichment updates, cached suggestions, and non-time-sensitive audiences
• Choose schedules that match when stakeholders actually use the data

See Schedule syncs in the UI to learn how to set up sync schedules.

Use sampling and fast queries for exploration

Audience and trait exploration often does not require exact counts on every interaction. Sampling maintains a smaller, regularly refreshed copy of your parent model, and fast queries tell Hightouch to use that sample for previews instead of scanning the full dataset. This gives you much faster audience sizes and previews in exchange for approximate (rather than exact) counts.

Fast queries are ideal while you’re brainstorming logic, validating filters, or comparing audience shape. When you need exact numbers—for example, right before go‑live, for small or highly targeted audiences, or for compliance/reporting—you can turn fast queries off to run against the full data.

Enable fast queries in audiences

1. Go to Customer Studio → Audiences.
2. Open an audience.
3. Enable the Fast queries toggle in the audience header, if available.

With fast queries on, Hightouch calculates audience sizes and previews using the sampled copy of your parent model so results return much faster, but counts are approximate.

Enable sampling in models

See Sampling to learn how to set up and use sampling for your audiences, including how to choose a sample percentage and refresh schedule.

Use full queries (fast queries off) for final audience runs, production syncs, and reporting where precision matters. Sampling keeps the UI responsive while reducing compute demand during exploration.

Control how many jobs Hightouch runs at once

Hightouch can run many jobs at the same time. This setting also controls concurrency.

Higher concurrency reduces how long jobs take overall but increases short-term compute usage.
Lower concurrency spreads work out over time and reduces peak load.

Match this setting to your warehouse limits and job timing requirements.

Monitoring and governance

To ensure warehouse usage matches expectations, monitor both cost and data access over time.

Recommended practices:

• Use a dedicated warehouse, user, and role for Hightouch
• Review warehouse-level credit usage trends
• Inspect query history to identify expensive queries and confirm improvements after changes
• Configure budgets and resource monitors to catch anomalies early