Warehouse tables reference

Hightouch creates and manages tables in your data warehouse to power change data capture, sync logging, audience snapshots, journeys, identity resolution, and more. This page is a single reference for all of these tables: which schema they belong to, which feature creates them, and how you should (and shouldn't) use them.

Usage guidance

Hightouch writes these tables to your warehouse for observability, debugging, and lightweight reporting. Before building on top of them, keep the following in mind.

Recommended uses

Ad-hoc debugging and auditing. Query sync logs to investigate failed rows, inspect audience membership changes, or trace a user's journey path.
Lightweight reporting. Build dashboards on top of sync run metadata, audience snapshots, or identity resolution outputs to monitor Hightouch activity.
Analytics and activation with Identity Resolution outputs. The _resolved, _resolved_identifiers, and _golden_records tables are explicitly designed for downstream use. You can query them directly, register them as dbt sources, or sync from them.

Not recommended

Wiring tables into production workflows. Don't build business-critical pipelines that depend on these tables without . Table schemas may change as Hightouch evolves, and we don't guarantee schema stability for all tables.
Writing to Hightouch-managed tables. Never insert, update, or delete rows in the hightouch_planner schema (especially JOURNEY_LOG tables and _plan/_rejections tables). These tables are actively used during sync and journey execution — modifying them can cause unexpected behavior.
Depending on internal state tables. Tables prefixed with IDR_ or IDR_BACKUP_ are internal to Identity Resolution. Don't query or reference them in pipelines — they can change without notice.

Documenting a table here doesn't mean Hightouch is committing to a stable schema contract. If you want to build durable integrations on top of these tables, so we can help you find the right approach.

Schemas overview

Hightouch uses up to three schemas in your warehouse, depending on which features you enable:

Schema	Purpose	Created when
`hightouch_planner`	Change data capture, audience snapshots, journey logs, Identity Resolution outputs, AI Decisioning tables	Lightning sync engine is enabled
`hightouch_audit`	Warehouse Sync Logs, holdout group logs, journey views, data extraction reports	Lightning sync engine is enabled; individual features populate specific tables
Custom (per Events source)	Event data (Hightouch Events); schema name is configurable	An Events source writes to a warehouse destination

hightouch_planner schema

Lightning sync engine (CDC)

These tables are created automatically when the Lightning sync engine is enabled. They're required for syncs using the Lightning engine.

Table	Key columns	Description
`*_plan`	—	Stores a model's query results for a sync run, used to compute row-level diffs. Table names change with every run.
`*_rejections`	—	Stores rows rejected during a sync run. Table names change with every run.

Hightouch only keeps the two most recent pairs of _plan and _rejections tables per sync. Because table names change with every run, Hightouch requires write access to the entire schema.

Don't delete tables from hightouch_planner. Removing CDC tables breaks change data capture and requires a full resync to recover.

For full details, see Lightning sync engine — Warehouse schemas.

Audience snapshots

Optional — must be enabled on the source's Sync Logs tab. See Audience snapshots.

Table	Key columns	Description
`audience_membership`	`ht_row_id`, `ht_audience_id`, `ht_timestamp`, `ht_event_type`, `ht_split_group`	Tracks audience membership changes over time. Each row records an `enter` or `exit` event for a member.

Journey tables

Created automatically when a journey is active. See Journeys — Journey Logs.

Table	Key columns	Description
`JOURNEY_LOG_<journey_id>`	`row_id`, `row_instance_id`, `from_node_id`, `to_node_id`, `event_type`, `timestamp`	Logs all row movement through the journey: entries, transitions, and exits.
`JOURNEY_METADATA_<journey_id>`	`journey_id`, `journey_name`, `node_name`, `node_type`, `node_id`	The journey graph structure and customer-defined node names. Updated on save.
`JOURNEY_CONTEXT_LOG_<journey_id>`	`row_id`, `row_instance_id`, `node_id`, `entered_at`, `[variable_name]`	Results of journey context variables for each row.

Don't write to JOURNEY_LOG tables. They're actively used during journey execution — inserting, updating, or deleting rows can cause the journey to behave unexpectedly.

The journey_id in table names is the journey's UUID with dashes removed.

Identity Resolution outputs

Created automatically when an identity graph runs. See Lookup table usage.

Table	Key columns	Description
`<output_prefix>_resolved`	`ht_id`, `source`, `primary_key`, `latest_timestamp`	Maps every input row to a resolved identity.
`<output_prefix>_resolved_identifiers`	`ht_id`, `identifier`, `value`, `first_timestamp`, `last_timestamp`, `count`	All identifier values associated with each resolved identity.
`<output_prefix>_unresolved`	—	Input rows that couldn't be processed, typically due to duplicate primary keys.
`<output_prefix>_golden_records`	`ht_id`, plus one column per configured field	One row per identity with canonical field values. Only created when Golden Record is enabled.

These four output tables are designed for your use. You can safely query them, reference them in dbt, or build views on top of them. For long-term stability, we recommend creating a view or derived table rather than transforming them in place.

Identity Resolution internal state

Table	Description
`IDR_` / `IDR_BACKUP_`	Internal tables for incremental processing and graph consistency.

Don't query or modify these tables. They're internal implementation details and can change without notice.

AI Decisioning

Created automatically per agent when using Hightouch-assigned groups. See AI Decisioning — Group assignment.

Table	Key columns	Description
`de_user_experiment_groups_<agent_id>`	`user_id`, `user_hash`, `experiment`, `first_seen_at`, `last_seen_at`	Tracks which experiment bucket (`treatment`, `holdout`, `customer_managed`) each user belongs to over time.

hightouch_audit schema

Warehouse Sync Logs

Optional — must be enabled per source or per sync. See Warehouse Sync Logs.

Table	Key columns	Description
`sync_changelog`	`sync_id`, `row_id`, `op_type`, `status`, `failure_reason`, `fields`	A log of every operation across all sync runs. Each synced row gets one entry per run.
`sync_snapshot`	`sync_id`, `row_id`, `op_type`, `status`, `failure_reason`, `fields`	The latest status of each row across all syncs. Replaced after each run.
`sync_runs`	`sync_id`, `sync_run_id`, `model_name`, `started_at`, `finished_at`, `status`	Metadata for each sync run, including row counts for planned, attempted, succeeded, and failed operations.

Holdout group logs

Optional — requires a feature flag and must be enabled on the source's Sync Logs tab. See Experiments — Holdout group logs.

Table	Key columns	Description
`audience_holdout`	`sync_id`, `sync_run_id`, `model_id`, `row_id`, `fields`, `split_group`	Logs rows excluded from a sync due to holdout group membership, for post-campaign analysis.

Journey views

Created automatically when journeys are active. These are read-only views that combine all per-journey tables into a single workspace-level view.

View	Description
`JOURNEY_LOG_VIEW_<workspace_slug>`	Combines all `JOURNEY_LOG` tables. Includes a `source_table` column to identify the originating journey.
`JOURNEY_METADATA_VIEW_<workspace_slug>`	Combines all `JOURNEY_METADATA` tables.

Find your workspace slug under Settings > Workspace > Workspace slug. Replace dashes with underscores in the slug when querying (for example, my-workspace becomes my_workspace).

Data extraction

Created automatically when data extraction is enabled for a destination. See Data extraction.

Table	Key columns	Description
`{destination-type}_{destination-id}_audiences`	Varies by ad platform	One table per enabled destination. Schema mirrors the ad platform's API response.
`external_audiences_metadata_v1` (view)	`ad_account_id`, `audience_id`, `audience_name`, `audience_size`, `ht_fetched_at`	A combined, standardized view across all destination tables.

Events schema

Hightouch Events writes event data into a configurable schema — not hightouch_planner or hightouch_audit. The schema name defaults to an auto-generated value based on the event source but can be configured in destination settings. Tables are created automatically when an Events source writes to a warehouse destination.

Table	Key columns	Description
`identifies`	`id`, `anonymous_id`, `user_id`, `<traits>`, `timestamp`	All `identify` events. Trait keys become separate columns.
`tracks`	`id`, `anonymous_id`, `user_id`, `event`, `event_text`, `timestamp`	All `track` events.
Per-event tables	Varies	A separate table for each track event type, with event properties as columns. Can be disabled.
`pages`	`id`, `anonymous_id`, `user_id`, `<properties>`, `timestamp`	All `page` events.
`screens`	`id`, `anonymous_id`, `user_id`, `<properties>`, `timestamp`	All `screen` events.
`groups`	`id`, `anonymous_id`, `user_id`, `group_id`, `<traits>`, `timestamp`	All `group` events.

For the full column-level schema, see Events warehouse schema.