Hi there,
I have reached out to the DV community on many occasions trying to get an answer to this question. I get that hubs, links and satellites are meant to keep business key, relationships and contextual information separate, but nobody can tell me WHY.
What benefit is there to structuring the data this way?
Hey Hook,
Hope you’re well. I might have a bit of an alternative take on this but it might give you some insight as to why I like this structure.
One of the main tenets of DV2 is high scalability through an insert only approach. This is cleanly implemented through hubs, links and satellites but as you mention it’s not the ONLY way to have an insert only structure.
What I like about the three main tables is that they allow us to not just think of records as insert only but expands on this idea to have an insert only architecture, where we only need to add additional tables to adjust to the ebb and flow of how a business changes.
Obviously there are pros and cons with any methodology and a DV2 architecture should always be pruned for any tech debt (like any project would) but these three tables allow us to significantly reduce the need to tinker with any old code or anything that is a potential risk to the stability of the end-users system
There are definitely other ways of looking at why we need hubs, links and sats but this is how most often enjoy thinking about DV2
Frankie,
Thank you for at least attempting to answer the question, and believe me, you are the first person that has responded with anything other than “it’s to separate business key, relationship and context”.
What I’m reading from your answer is that this architecture offers some kind of “conceptual clarity”, which helps when we expand the model. It’s a great idea, but things are never so simple in practice.
The problem I have with this approach is how to handle relationships and, therefore, how to create links. Assuming most Data Vault models are built incrementally (as recommended), there is no way to know that the links we build today will fit new data we bring in tomorrow. We often find that the new data will suggest that the links we built before are now incorrect.
As an add-only paradigm, the Data Vault way is to create new links and refactor pipelines to target the new structures while leaving the old stuff alone. After a few iterations, it isn’t hard to see that the model will begin to get out of control and that any engineering effort will spend a disproportionate amount of time on remedying technical debt rather than bringing in new data.
It isn’t sustainable, and it is one of the main reasons I see Data Vault projects failing. So what is the alternative? What if we didn’t separate the data into hubs, links and satellites? What if we collapsed the business keys down into the satellite?
Consider a simple Data Vault scenario. Say I want to ingest a source table, and it contains three legitimate business keys (Customer, Order and Product). Firstly, I need three hubs; one for each business concept. Then, I need a link associating the three hubs, or is it? Maybe it’s two links: Customer<->Order and Order<->Product? Or maybe there is a third Customer<->Product? Then the satellite, which I need to hang off the link (which one). I’ve only brought in one source table and I’m not entirely sure I got the model right. Imagine scaling that up to hundreds or thousands of tables!
If I were to collapse the business keys into the satellite, then I wouldn’t need to worry about any of that. I will have a table containing three business keys, and I didn’t waste a scrap of energy thinking about what relationships to model. Does that model contain everything the equivalent DV model does? What did we lose? When I bring a new source table into the “model” which might suggest a different relationship between the business concepts, I don’t need to go back and refactor the old table.
So I am still waiting for that ‘ahh-ha’ moment, but I don’t think it is coming. I believe it’s done this way because it’s always been done this way. Data Vault was created in a time before we had massively parallel distributed database systems. Maybe back then, splitting the data in this way might have had some performance benefit, but those days are long gone. Splitting data into hubs, links, and satellites is what makes a Data Vault a Data Vault, but I see no practical or performance benefits for this approach any more.
Hi Hook,
You already have a very established view of DV and why you don’t agree with the way it works, so I believe my comment won’t change that, but I will give it a try.
When you have only the business keys that uniquely identify your business entities in one structure, you can look for the information you need faster, only using that column to slice and dice your data.
The hubs act as an index for your data that allow you to write to the database and read fast.
The links capture the relationship as you already mentioned in both your question and your comment to the previous answer.
As long as the relationship is valid for the business then the link is valid.
In other words if a customer place an order, or if an order has products, define the relationship.
You want to keep this relationships described in the smallest grain possible in the unit of work for that particular set of business entities.
If you can have only 2 business keys that capture a unique relationship then that is the way to go.
As long as a costumer place orders, that relationship holds true and also the link in your DV.
Again holding only business keys, you can quickly retrieve or write the data to the database.
Finally when you connect the satellite or group of satellites, the question you need to answer is what are these attributes describing, in our example can be, the costumer, the order or the specific products in the order.
Of course you can do as you say and put the keys together with the data following the primary key and foreign key principles and then create a star schema around it, but that reduces the flexibility to write and read from the database.
Data Vault separates the writing step from the reading step allowing for parallel writing, on the other hand when separating the data in this 3 basic structures is easier to integrate multiple systems in the same data system.
For the reporting side of things, you can read the data from the Vault and give it the shape you need.
This basic constellation built with the hub, satellite and link allow for scaling the warehouse fast, in small increments that can fit in a couple of sprints delivering value faster to the business.
I hope this provides more elements for the discussion on WHY DV does the data model in this specific way.
Hi Ricardo,
I guess I do have an established view which has taken me many, many years to arrive at.
I’ve read Dan’s books and Hans Hultgren’s books. I’m a certified Data Vault 2.0 Practitioner (CDVP2) and a Certified Business Concepts Maven (CBCM). Lots and lots of theory, and it all makes sense… until you try to put it all into practice.
Over the past few years, I’ve been directly involved with, or seen first hand, Data Vaults in multiple organisations and, with perhaps one exception, they have all failed. There must be a reason for this. So I ask questions, and I challenge assumptions.
The main issue I see is the modelling of links. It’s challenging to get them right, and more often than not, you don’t. What would Data Vault look like if you got rid of links? Rather than placing the Hub references in a Link table, push them down into the satellite.
We lose the formal definition of a “Unit of Work”, a concept that has always baffled me. However, the satellite still defines the relationship as a tuple of business keys. There is now no distinction between hub and link satellites.
We can still maintain Hub tables. But we can also challenge that assumption. What do we lose by getting rid of Hub tables? OK, I get that the Hub table gives us a superset of all business keys across all data assets, but how useful is that? How often do we actually need to join to a Hub table?
What are the benefits of this approach? In a word, simplification. “Modelling” is now redundant. All you have to do is identify business keys, and the relationships look after themselves. Load patterns are almost trivial: one table in and one table out, no modification to the data, and you can run as many in parallel as you like (no dependencies). The pattern is so simple that you could implement it using views.
Does it work? Absolutely. The approach is called ‘Hook’, and over the past couple of years, I’ve implemented it in two organisations. Now, there is interest from companies further afield.
I would challenge anybody considering a Data Vault implementation to look at Hook. But don’t take my word for it; put them side-by-side and see what works best. I think you’d be surprised…
So I’m confused, is this an advertisement?
By your description it sounds like you’re trying to re-invent Inmon style relational databases and slap your name on the cover, but I’m happy to read up on new methodologies so I’ll take a look. I think the real answer here is that by merging these tables your lose one of the many nice bonus of the equivalent DV2 model so I’d be intruiged how you get around these challenges.
Still a bit confused what you were aiming for with this question now that I know you’ve written a full book on this very topic?
Hey Frankie,
Have you ever been in a situation where something seems so obvious that you believe you must be missing something, but you just can’t see it?
That has been my state of mind for the past three years after I conceived the Hook approach. I must be missing something, but what is it? That’s why I ask these questions.
I know from recent experience that Hook is a much simpler, more efficient and agile method for data warehousing; I don’t need to, and I’m not trying to, convince you of this. What I am asking for is, what am I missing? What magic benefits does Data Vault give me that Hook doesn’t? What critically important features am I missing that makes Data Vault the obvious choice?
You said:
“… by merging these tables, you lose one of the many nice bonuses of the equivalent DV2 model, so I’d be intrigued how you get around these challenges”.
What bonuses and challenges are you referring to? Maybe there is something in there that I’ve missed…?
Different data modelling techniques suite different architectures. If your data architecture does not support ANSI compliant SQL semantics on a relational database, you should probably consider something other than data vault — and yes, throwing Spark at something doesn’t make the data storage architecture relational, it makes it a band aid, a very expensive one.
Why separate them? Easy. Like the design of Kimball models the design of DV models must take advantage of the OLAP platform’s algorithms underneath the hood, to name a few:
The hash join is important, it’s what makes joining facts and dimensions so performant, and when I see a customer build “PIT views” I know they are missing this lesson entirely.
We also preach that your data complexities should be shifted as far left as possible, the theme of this article, The OBT Fallacy & Popcorn Analytics | by Patrick Cuba | The Modern Scientist | Medium
It is not documented anywhere that you shouldn’t have business keys in satellite tables, I encourage it. Why do you need to join to anything if you do not need to?
Why have those separate tables?
Coincidently many of these topics is exactly what I discuss here: Data Vault is Information Mapping | by Patrick Cuba | The Modern Scientist | Mar, 2025 | Medium
And very doable using Iceberg too, Data Vault on Snowflake and Apache Iceberg | by Patrick Cuba | The Modern Scientist | Medium
Why do I blog these? Because it helps with consultation with customers. How many times when you’re explaining these concepts to an audience and at the end of the call they ask a question you already answered at the beginning of the call! Cognitive load! Sometimes, whilst consulting I might even say, “ah, I have a blog for that, here you go!”
We always recommend training and coaching but I think it is a cheat to simply say, “you’re doing it wrong because you never had training” or worse, “pay me money so I can show you how to do it.” Let me tell you, even trainers get it wrong. No where in the training material do they tell you why the structures work as tables, they just tell you to do it. Or worse, stating that there are problem statements like “link-satellites are dead” without providing any evidence of the problems they encountered. Or spend pages discussing the “colours of DV” — what is the value in that?
I have been trained and certified on both Data Vault variances, so I can see plainly when I’m consulting which DV a modeller models just by looking at it.
It is not helpful going round and stating that you have seen many failed data vaults when the common denominator is yourself, I’m sure you have seen success in your hook (or even share when it has not worked). I won’t defend data vault because I know it is not perfect and I know where and (a lot of the times) why pitfalls occur. A common issue I see is, “we want to build a data vault”, I ask “why”. I would be happy to say “no you shouldn’t” and there can be a host of reasons,
Check out the comment section of this article, The Death of Hash Keys. An innovation introduced in data vault… | by Patrick Cuba | The Modern Scientist | Feb, 2025 | Medium
I don’t understand why people are still trying to import hash-keys into PowerBI or Tableau!
Where I have seen it work and work quite well is when customers have a clear vision of what their business architecture looks like. That you’re not building a DV as just another modelling technique but as paradigm shift to thinking of structuring data around business needs. i.e. marrying Enterprise Architecture discipline with how the data is structured.
The pitfall I see here is employee churn and knowledge retention, enterprises must invest in the discipline to continue following principles established on how they will build their data vault, trust me, there’s even variances within the two dominant DVs in the wild!
Have you posted your question to Dan’s forum yet?
Hey Patrick,
That’s quite the stream of consciousness, but you make some interesting points.
I don’t see how splitting the data across different table types specifically optimises the DBMS performance. Fewer joins for querying and fewer tables for loading have to be better, but the only way to prove that is to put the methods side-by-side. I have asked/challenged the community, but there don’t seem to be any takers. When Hook starts to get more of a foothold, I’m sure that will happen, and I welcome it.
However, there is more to any data warehousing method than performance. It has to be useable and easily learned. Modelling has to be intuitive and agile. As you point out, you can’t set out on the Data Vault path unless you are committed and really well prepared. There is a lot to learn and a lot to practice, requiring considerable investment in architecture, tools and, more importantly, people. This is why I see so many Data Vault projects fail: because most organisations dive into it half-cocked and expect the success that they were promised. That commitment is too high for most organisations. Still, there seems to be some deep-seated perception that Data Vault is the only credible method for building a successful data solution. So they forge ahead regardless and wonder why it all goes wrong.
Like you say, even experts can get it wrong, so what hope is there for the rest of us? If success is predicated on the experience and expertise of somebody like you, Patrick, then there is something wrong with the approach. You are not most people.
Another sticking point is Data Vault’s modelling approach. If you glance through the questions on this forum alone, it is clear there seems to be a tremendous amount of confusion about how to go about it. Which modelling approach? Data Vault 2.0 or Ensemble? Do we model incrementally, one use-case at a time, or should we invest time upfront in modelling a broader model? When (not if) we get the model wrong, how easy is it to change it? Why is it so hard?
My comments about failed Data Vault projects might not be helpful, but the reality is that if my experiences with Data Vault had been positive, then Hook would not exist. Hook is my attempt to create a method that is just easier and to remove as many barriers that methods like Data Vault seem to put in our way. I probably shouldn’t comment further, especially on a public forum, but I have some interesting anecdotes I’d happily share over a beer. Similarly, I could and would love to comment on my Hook experiences, but not here. Has it been plain sailing? Of course not. Hook is still relatively new, and there has been much to learn and new situations to understand. But it is now reaching a level of maturity that I feel comfortable with. By that, I mean that is Hook has reached a level where it should be included in the conversation for any organisation thinking about their next warehousing project.
Finally, to answer your question,
“Have you posted your question to Dan’s forum yet?”
As you know, the Data Vault Alliance changed its forum to a moderated format some time ago. Before that, I posted numerous questions like this and never received any satisfactory answers. Since the change, I have tried again, but my questions never get past the moderators, further reinforcing my belief that I’m on to something. Dan no longer engages with me after he tried to call me out on LinkedIn, but I think those comments have long since been deleted…
There’s your problem right there
I’m actually the only local resource in customer calls across the globe because of this
Many don’t even know this
It exists because you put it there, and it might work for you and so be it.
I still post there and highlighted my XTS blog that they deleted from DVA.
You should post there, after all, a discussion between one inventor to the other would be at least entertaining… better yet, start a hook forum.
There’s your problem right there.
Apart from the comment being somewhat dismissive (I’m sure you didn’t mean it to be), the argument just does not hold. Should I blindly accept that splitting data across different table types improves performance? I couldn’t say one way or another, which is why I’m suggesting a side-by-side comparison. We need some empirical evidence. Maybe Data Vault does perform better, but maybe it doesn’t, but surely you wouldn’t expect me to just take your word for it.
You were critical of similar behaviour regarding Data Vault training:
We always recommend training and coaching but I think it is a cheat to simply say, “you’re doing it wrong because you never had training” or worse, “pay me money so I can show you how to do it.” Let me tell you, even trainers get it wrong. No where in the training material do they tell you why the structures work as tables, they just tell you to do it…
I’m asking the question because I don’t understand, so please enlighten me; don’t dismiss me. Explain it in terms that I can understand, and then I can explain it to the next person who asks me. At the moment, I have nothing.
Again, I didn’t say that, I provided links for you to traverse and you have dismissed it by asking the same question again. 
Many of the techniques that these enable are in my large catalogue of medium blogs — have fun!
Hello Andrew! Nice to see you in this forum.
I think it is split due to normalization of data. “best of breed between 3rd normal form (3NF) and star schema.” The goal is to reduce data redundancy and by that make data retrival faster. The question is if it is really faster?
I try to explain from the point of view from my knowledge in RDBMS.
So we have 2 options:
And lets say we should select the latest data that was inserted into the satellite with its business keys.
For case 1 we need to join between the hub and the satellite on the joinkey.
For case 2 we dont need to join.
Case 2 will perform faster.
But if the business key is far larger then the joinkey, ex nvarchar(52) is a lot larger than a binary(16), there will be a threshold for when Case 1 starts to perform faster than Case 2.
So it depends on the size of your business keys and what datatype you use for the joinkey.
There is also a third option to put the businesskey beside the joinkey in the satellite (something that is recommend by someone). Question is if the hub is really needed then?
But I think you already know this! 
Hey Andreas,
A couple of things.
Your point about the size of hash keys versus the raw business key is a consideration. I seem to remember that Roelant Vos did some analysis on this a few years back and concluded that in most cases business keys are typically smaller than their hash key. I can’t remember but I think he was basing this of a 32byte hash so using smaller
You also said (I think) that splitting the data into hub, links and satellites is a form of normalisation. I think this is another of those urban myths that Data Vault advocates often cite as a way to sell the methodology. I don’t think that is true at all. Splitting the data in this way doesn’t change the level of normalisation in any way. When loading data into the vault we’re not normalising the data we’re deconstructing it, which won’t give us any performance advantage, because to reconstruct the data we’d have to join it all back up again.
Andrew, i dont agree on your take on performance. Reconstructing data does not equal worse performance. To retrieve the latest data from a delta satellite, an aggregate function must always be performed (select bk/hk, max(loaddate) as LD from deltasatellite group by bk/hk) and then a join back to the same deltasatellite on bk/hk and LD has to be performed to get all descriptive data. The aggregate function will go faster if the datatype of the bk/hk is small. The join back to the table will go faster if the datatype of the bk/hk is small.
The join to the hub has to be performed, but if the join to be hub is “cheaper” than difference(hk or bk) in performance of the aggregate function and the selfjoin then this reconstruction of data is more performant. So I say that it can be more performant to reconstruct the data if the datatype of the businesskey is larger than the hashkey.
But as Roland Vos concluded, most businesskeys are smaller than the hashkeys.
Hash keys has had a good run, The Death of Hash Keys. An innovation introduced in data vault… | by Patrick Cuba | The Modern Scientist | Medium
Not really, I have shown techniques for bloom filtering which negates the need for doing this.
Interesting, can you provide me with an example where you use Bloom filtrering in sql?
I see, can you provide me with the sql code that extracts the latest bk/hk from a satellite without using any type of preprocessed storing technique?
Bloom filters work by providing a lookup table to join on, it’s a an equijoin — you can watch me do it here: Zero to Data Vault on Snowflake - Snowflake