One satellite per source system, plus a further split wherever a rule of thumb says attributes change fast, is the most expensive habit in Data Vault satellite design. And you didn’t 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. On a relational engine, that made one narrow satellite per source system pay off. Fewer bytes came off disk, load windows stayed independent, and there was 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 doesn’t cost you sixty columns when a query asks for five. 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. 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’re 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 isn’t new. The Data Vault literature, Linstedt and the Data Vault Alliance included, calls a multi-source satellite an overloaded satellite. The literature warns that competing values from different systems will flip-flop through that satellite’s history.

But what does that warning actually describe? 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 wasn’t a Data Vault common satellite. It was a union of unrelated source schemas sharing a table. 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’s 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 a rule of thumb or on which system fed the data.

Conforming is now the whole job

The difficulty doesn’t disappear here. It moves. The hard question stops being physical (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 can’t 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’s 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. 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’s the measured change profile the split should rest on, rather than a rule of thumb.

Every loaded row records the source it came from. For Data Vault on Databricks, the generated Lakeflow code builds each satellite as a versioned, insert-only load that keeps 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’s 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 doesn’t 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.

The old rules say nothing about that second question, and the gap runs wider than one question: Data Vault needs new rules for the lakehouse.