Split a Data Vault satellite on a business boundary, or on a rate of change you have measured, and on nothing else. On a lakehouse, the old load-mechanics reasons (storage, joins, change detection) no longer justify a split. What’s left is the cost. A satellite boundary is a hash boundary, and it isn’t a line you can move later.

You split that satellite because the account balance changes hourly and the date of birth doesn’t. On a relational database warehouse, that was the right call. On a lakehouse, every reason behind the split has moved into the platform. Parquet columnar storage handles the footprint, generated views handle the joins, and AUTO CDC handles the change comparison. What the split still does reliably is freeze the model in place.

Is rate of change still a reason for Data Vault satellite splitting?

What survives is row count. Your history is still noisy, and that part of the old argument holds up. It’s a row count problem rather than a storage footprint problem. So how do you tell a real gap from a hunch? Measure it.

The Analyze fast-changing attributes action returns split recommendations grounded in distinct cardinality, row counts, and null ratios. You can see whether the fast columns really out-change the stable ones by orders of magnitude, or merely feel like they do. The action also says so when profiling is missing, instead of filling the gap with a guess.

Where the gap is that wide, a split earns its keep. Where the gap is narrower than it looked, leave the satellite wide and let the generated views hide the noise from your consumers.

The Data Vault canvas splitting one satellite into two, a boundary drawn on measured change rather than on a hunch

Generated views hide the satellite layout from consumers

Joins were always the counter-argument to splitting. Five narrow satellites mean five joins for anyone reading the vault. Generated views settle that argument. For each table, DeltaVault, a Data Vault automation tool for the lakehouse, generates a current view and an end-dated view:

  • The current view keeps one row per key, with the newest load winning.
  • The end-dated view carries an effective-from and an effective-to timestamp on every version.
  • Point-in-time and bridge tables go further and reconstruct a hub with its satellites as of any date you ask for.

Nobody hand-writes those joins. Once the read shape is generated, your consumers query the view instead of the layout underneath it. The physical split stops being a query performance decision in either direction.

A hash diff is a boundary you cannot move

Here’s the cost nobody prices in. A hash diff covers exactly the columns in its own satellite, so every boundary you draw is a hash diff boundary. Move one column from the fast satellite to the slow one next quarter and the historical hashes on both sides stop being comparable. From there you have two options, and neither is pleasant. Recompute the history, or accept a spurious change row on every key at the cutover.

Wide hashes fail in the opposite direction. A wide hash tells you that something changed and nothing at all about what changed. And one badly behaved column is enough to poison the whole thing. Trailing whitespace, a timestamp whose precision drifts, a float that formats differently on the next load, and suddenly every row looks new.

Warning: DeltaVault warns you before you save a change to keys or hashed columns that would alter hash values, because it does not reload materialized tables for you.

Read that warning as the general rule rather than a one-off dialog. A physical split is the least reversible decision in Data Vault modeling, and the business model is the thing most likely to change.

Let the platform detect the change

The load-mechanics case for Data Vault satellite splitting always came down to the change comparison itself, and on Databricks that comparison now runs for you. DeltaVault generates each satellite as a versioned, insert-only load. The load matches on the parent’s hash key and the load date, compares each arriving row against the current version, and appends a new version only when something changed. So the full history of every row survives, as in a slowly changing dimension type 2. Upstream of the vault, the staging output runs as an AUTO CDC flow, the change data capture Databricks provides.

Keys, sequencing, delete handling, and history type all come from metadata you have already captured. There’s no per-satellite comparison logic left for you to hand-write, and nothing to keep in step when the model moves.

Split for meaning, not for mechanics

So what still earns a satellite of its own? A boundary in the business model earns one, and so does a rate of change you’ve measured. A boundary in the load mechanics never does, and neither does one satellite per source. It’s meaning before machinery, applied to satellites.

Start with the clearest case. A regulatory erasure rewrites files. So if personal data sits in its own satellite, that erasure touches a small table instead of rewriting a billion rows of balance history. That’s a business boundary, and you’ve already recorded it. DeltaVault carries Sensitivity, Personal Data Categories, and Regulatory classifications on business entities and attributes, alongside retention policies.

Rate of change still counts when it differs by orders of magnitude. That’s something you measure rather than feel.

When a boundary turns out to be wrong, reshape it rather than rebuild it, all on the canvas:

  • Split a satellite’s columns by subject.
  • Merge satellites.
  • Re-parent one from a hub to a link.

DeltaVault records each edit as a remodeling override, so the next acceleration honors it.

Aim for fewer, wider satellites shaped by the business model, with every exception carved out for a reason you can name. Those are the Data Vault lakehouse rules. Open your vault model and count how many of your splits survive that test.