Split a Data Vault satellite on a business boundary, and on nothing else. On a lakehouse, the old load-mechanics reasons (storage, joins, change detection) no longer justify a split, because the platform has absorbed all three. What is left is the cost: a satellite boundary is a hash boundary, and it is not a line you can move later.

You split that satellite because the account balance changes hourly and the date of birth does not. 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.

Should you still split satellites by rate of change?

What survives is row count. Your history is still noisy, and that part of the old argument holds up. It is a row count problem rather than a storage footprint problem. Treat it as a measurement, not a hunch: the Analyze fast-changing attributes action returns split recommendations grounded in distinct cardinality, row counts, and null ratios, so you can see whether the fast columns really do out-change the stable ones by orders of magnitude or merely feel like they do. It 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 DataVault designer with Splitting Satellites

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 is 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 Databricks now runs that comparison for you. DeltaVault generates each satellite as a streaming table fed by an AUTO CDC flow, the change data capture Databricks provides. That flow keys on the parent’s hash key, sequences by the load date, writes only genuine changes, and maintains the table as slowly changing dimension type 2, so the full history of every row survives.

Keys, sequencing, delete handling, and history type all come from metadata you have already captured. There is 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, never a boundary in the load mechanics, and never one satellite per source either. It is 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 is a business boundary, and you have 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, and that is something you measure rather than something you 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.