What Is a Satellite in Data Vault?

Hubs say what exists. Links say how things belong together. Neither stores a name, a balance or a status. That is the job of the satellite.

In classical modeling terms: the attributes of an entity, its context, become a satellite. Where the Customer table carries name, address and segment next to customer_number, the Data Vault keeps the number in the customer hub and the attributes in a satellite on it.

What a satellite is

A satellite holds the descriptive attributes of a hub and every change to them over time. When a customer moves, the satellite does not overwrite the address: it appends a new row, and the old one stays. Each row records when it entered the vault and which system delivered it, so every version is traceable.

If you know dimensional modeling, a satellite is a slowly changing dimension type 2, without ever running an UPDATE. Historization can also be switched off on request, which gives a non-historized satellite.

The anatomy of a satellite

The primary key is the parent hash key plus the load date.

The hash diff is a choice, not a rule

Textbook Data Vault says to compute a hash diff for every satellite row to detect changes. In practice it depends on the load:

• Delta loads: the stored rows already carry their hash, so hashing only the incoming rows is cheap. The hash diff wins.
• Full loads: hashing millions of rows on every run costs CPU. A direct column comparison (IS DISTINCT FROM) is often faster on modern engines.
• Wide tables: the common claim is that wide tables benefit most from hashing. The opposite is closer to the truth: wider rows mean longer string concatenations to hash.

Datavault Builder supports the hash diff as an option, not a mandate. The hash diff gets its own article in this series.

Transactions get their own satellite

Quantities, prices and amounts of an order line describe the transaction itself. With a grain hub for the order line, as described in the article on links, they go into an ordinary satellite on that grain hub, where they are historized like any other attribute.

How to split satellites

• By source system. CRM and ERP data never share a raw satellite. Each source keeps its own lineage, unchanged.
• By rate of change. A daily balance and a legal name in one satellite copy the name into a new row every day. Fast and slow attributes belong apart.
• By sensitivity. Personal data such as name, email and date of birth goes into its own satellite, apart from attributes that identify nobody. GDPR reporting then has one clear place to look, and access rules or a deletion request apply to that satellite alone.
• Never delete. When a record vanishes in the source, its history stays. A record tracking satellite marks that the key is no longer delivered. The exception is a legal obligation to remove information, such as a GDPR erasure request, and that is where splitting by sensitivity pays off.

What changes with Datavault Builder

You map source columns to a satellite in the model. Change detection, the append-only load and the audit columns are generated, and run natively on Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle or PostgreSQL. Two situations that classic load patterns do not handle are covered out of the box:

• Bi-temporal loads. A financial institution with end-of-day processing has two timelines: when something was true for the business, and when the warehouse loaded it. Datavault Builder processes the end-of-day history and the load history together and creates bi-temporal satellites. See bi-temporal data processing for how it works; bi-temporality also gets its own article in this series.
• More than one change per load. A data lake often delivers several versions of the same record in one batch. Classic patterns load one change per key and run, so you would have to loop over the data, and every version would be dated to the moment of the load. Datavault Builder loads all changes in one batch and places each record on the timeline where the data lake recorded it.