One satellite per source system, plus a further split whenever attributes change fast, is the most expensive habit in Data Vault satellite design, and you did not invent it. You inherited it from row-store databases. On a columnar lakehouse, the physics that justified that split no longer hold. The very design that made your vault fast on a relational engine is what makes it slow on Delta Lake and lakehouse platforms.

Why did we split satellites by source system?

Row stores read whole rows, every time. That is why one narrow satellite per source system paid off on a relational engine: fewer bytes off disk, load windows that stayed independent, and no contention between systems running on different schedules. Physical isolation bought you performance you could measure.

Delta Lake is Parquet underneath, and Parquet is columnar, so the arithmetic changes. A satellite with sixty attributes does not cost you sixty columns when a query asks for five, because the engine reads only the five it needs. What you still pay for is the join. Every satellite you split off adds another scan, another key match, and another chance for the optimizer to pick a bad plan.

On a columnar lakehouse, width is cheap and the cost has moved to the joins, so the split that once bought you speed now charges you for it.

You are fragmenting attributes you already plan to rejoin

Your sales platform, your finance system, and your self-service portal each carry a customer name, an email, a phone, and a status. Split those by source and you get three satellites holding the same handful of business attributes, a source-shaped vault one system at a time. Two more systems land, and you are maintaining five.

Then you build the customer dimension on top of them. Before a single line of consolidation logic runs, you have to pull the current rows out of all five satellites and rejoin them. Those are exactly the joins that width no longer buys you back, and you pay them on every load to undo a decision you made once, at design time.

Flip-flopping attribute values are a conforming failure

The objection is fair, and it is not new. The Data Vault literature, Linstedt included, calls a multi-source satellite an overloaded satellite and warns that competing values from different systems will flip-flop through its history.

Stay with what that warning actually describes. Two systems writing different values into the same attribute, load after load, is evidence that the two columns were never the same business attribute to begin with. What you built was not a Data Vault common satellite. It was a union of unrelated source schemas sharing a table, and the flip-flop is the model telling you so.

When you should still split

Read it that way and the three cases sort themselves out.

  • Where the attribute really is shared, the systems agree and there is nothing to flip.
  • Where it genuinely belongs to one system, it belongs in an extension satellite rather than the common one.
  • Where a group of attributes churns far faster than the rest, you split on the measured change profile rather than on which system fed the data.

Conforming is now the whole job

The difficulty does not disappear here, it moves. The hard question stops being physical, meaning where you split the data, and becomes semantic: is the sales platform’s customer name the same business attribute as the finance system’s account name?

You cannot route around that question, and no tool answers it for you. Conform the business attribute first, or you never get a common satellite at all.

How DeltaVault makes the agreed attribute the vault’s backbone

That agreement is metadata, and it is what DeltaVault is built around. Business attributes are real catalog objects here, not names in a spreadsheet that someone maintains by hand. Map & Match proposes the business entity behind each source table and the business attribute behind each column, and every suggestion carries a confidence score and a written rationale grounded in catalog evidence rather than naming similarity. Accept it, and every mapped column, in every source system, points at one agreed attribute.

Once that agreement exists, you shape the vault instead of retyping it. You split and merge satellites directly on the Data Vault canvas, so moving a single-system attribute out of the common satellite and into an extension satellite is a modeling decision, not a rewrite. Run Analyze fast-changing attributes and the split recommendations come back grounded in measured profiling: distinct cardinality, row counts, and null ratios. That gives you the measured change profile the split should be based on, rather than a rule of thumb. Every loaded row records the source it came from, and for Data Vault on Databricks the generated Lakeflow code turns each satellite into an AUTO CDC streaming table that retains the full history of every row.

One customer hub carrying a single shared satellite, with the link, point in time and bridge objects built around it rather than a satellite per source

That is the shape to aim for: one hub, one satellite carrying the agreed attributes, and the landing tables of every source system feeding it.

Your vault does not need more satellites. It needs fewer, agreed ones.

  1. Map your second source onto the attributes your first already defined.
  2. Look hard at what a NULL means in the satellite you just consolidated.

That question is the next thing this changes, and the old rules say nothing about it: Data Vault needs new rules for the lakehouse.