Architecture guide
Data hub vs data fabric vs data lakehouse
Five architectural patterns get compared as if they were competing products. They are not. Each answers a different question, and picking the wrong one is usually what turns a two-quarter project into a two-year one. This is the plain-language version, with the trade-offs left in.
The short answer
| The question it answers | Where the data sits | What it optimises for | |
|---|---|---|---|
| Data warehouse | What are our agreed historical numbers? | Copied in, modelled on write | Query performance and consistency for known questions |
| Data lake | Can we keep everything cheaply until we know what we need? | Copied in, raw | Storage cost and format flexibility |
| Data lakehouse | Can we get warehouse behaviour on lake storage? | Copied in, open table formats | One storage layer serving BI and ML |
| Data hub | What does this entity mean across every system? | Left in place, mediated and governed | Shared meaning, governance and time to first value |
| Data fabric | Can access, policy and discovery work uniformly across a distributed estate? | Left in place, virtualised and metadata-driven | Uniform access and automation across many systems |
| Data mesh | Who owns this data, and can they ship it as a product? | Owned by domains | Organisational scale and accountability |
Notice that only two of the six rows are really about technology. Warehouse, lake and lakehouse are storage and compute decisions. Hub and fabric are meaning-and-governance decisions. Mesh is an operating-model decision. Comparing a lakehouse to a data mesh is a category error, which is why those debates never resolve.
What a data warehouse is for
A warehouse takes data out of the systems that produced it, conforms it to a model designed in advance, and stores it for analysis. The model is the point: because someone decided what “revenue” and “customer” mean before the data landed, everyone querying it gets the same answer.
That strength is also the constraint. Modelling on write means every new question that the model did not anticipate requires schema work, and every new source requires a pipeline. Warehouses are excellent at the questions you knew you would ask and slow at the ones you did not.
What a data lake is for
A lake inverts the trade. Land everything cheaply in raw form, decide what it means later. It solved the cost problem and created a governance one: without imposed meaning, a lake accumulates files nobody can vouch for. The industry phrase for the failure mode — data swamp — exists because it was common.
What a data lakehouse is for
A lakehouse is the reconciliation: open table formats such as Delta, Iceberg and Hudi bring transactions, schema enforcement and time travel to lake storage, so one copy of the data can serve BI and machine learning without maintaining a separate warehouse alongside it.
It is a genuinely good answer to a genuinely real problem — but it is still an answer about storage. A lakehouse does not tell you that the customer ID in your CRM and the account number in your billing system are the same company. It gives you an excellent place to put both, and leaves the resolution to you.
This is the most common expensive misunderstanding we see: a team adopts a lakehouse expecting the disagreement between departments to end, and finds that it has simply moved the same disagreement into a better-performing store.
What a data hub is for
A data hub is a governed point of mediation. Rather than being defined by where bytes are stored, it is defined by what it guarantees: that an entity — a customer, a supplier, a part, an employee — resolves to one identity across every system, that every metric has one definition, and that any figure can be traced back to the source record it came from.
The architectural consequence is that the data does not have to move. The hub connects to the systems that own the data, resolves entities across them, captures lineage as data flows, and serves a governed view to whoever asks. Source systems stay authoritative; the hub supplies the shared meaning they never agreed on.
That is why hub projects tend to produce something usable early. There is no consolidation milestone to clear before the business sees a working view — a typical deployment reaches a live 360 view in about 60 days, and a full hub is live in 60–90.
The trade-off, stated honestly: a hub depends on source systems being reachable and reasonably available. If your sources are slow, undocumented or locked behind a vendor, that cost surfaces in the hub rather than being hidden by a nightly copy. In practice this is usually where non-invasive SAP extraction earns its keep, because SAP is the source most often described as unreachable.
What a data fabric is for
A data fabric is the broader idea that a distributed estate should behave like one system: metadata drives discovery, policy is enforced uniformly wherever the data sits, and access is virtualised so consumers do not need to know which system a field came from.
Hub and fabric overlap enough that vendors use the words interchangeably, which does nobody any favours. The useful distinction: a hub is a place where meaning is resolved and governed; a fabric is a property of the whole estate — uniform access, policy and automation everywhere. A hub is often how a fabric gets built in practice, because uniform meaning has to be established somewhere before it can be enforced everywhere.
What a data mesh is for
Mesh is the only one of the six that is primarily about people. Its claim is that a central team will always be the bottleneck, so the domains that produce data should own it and publish it as a product, with federated governance keeping the whole coherent.
It scales beautifully in organisations that already have strong domain engineering teams, and stalls in organisations that do not — because “every domain owns its data products” assumes every domain has someone who can build one. Mesh is an organisational commitment before it is an architecture.
How to tell which one your problem needs
Ignore the labels for a moment and ask which of these sentences sounds like your organisation.
“Our reports are slow, and the numbers are agreed.” That is a storage and compute problem. Warehouse or lakehouse.
“We are throwing away data we might need, and storage costs are the blocker.” Lake or lakehouse.
“Finance, operations and sales walk into the room with three different numbers.” That is a meaning problem, and no amount of storage will fix it. Data hub.
“We have a dozen platforms and cannot enforce one access policy across them.” Data fabric.
“The central data team is a two-quarter queue and the business has stopped asking.” That is an operating-model problem. Data mesh — if the domains can carry it.
“Our AI pilots demo well and never reach production.” Almost always a meaning and governance problem. A model grounded on ungoverned data produces answers nobody can defend, which is where pilots quietly die.
They combine more often than they compete
The realistic end state for most large enterprises is not one pattern. It is a lakehouse holding the analytical bulk, a hub supplying governed meaning across the lakehouse and the systems that were never going to be consolidated into it, fabric-like policy enforcement across both, and mesh-style domain ownership wherever the domains are strong enough to carry it.
Anyone selling you one of these as a replacement for the other four is selling a product, not an architecture.
Where SCIKIQ sits
Now the pitch, having answered the question first.
SCIKIQ is a governed enterprise data hub with fabric properties. It connects 187+ sources where they already run — including no-code, non-invasive SAP extraction from S/4HANA, BW/BW4HANA and ECC — resolves entities into golden records, captures lineage continuously, and publishes governed metric definitions into a semantic knowledge graph. Policy-as-code, quality rules and trust scores apply across the estate rather than per system, which is the fabric half.
Activation sits on the same layer: a plain-language copilot and an agent factory that resolve questions against governed definitions and traceable lineage, not raw tables. It works alongside a lakehouse rather than instead of one — the lakehouse becomes a governed source among many.
If your problem is the third sentence in the list above, that is the shape of the answer.
Explore further
- Enterprise data hub — 187+ connectors, governed and unified in 60–90 days
- Data Fabric — the knowledge graph and semantic layer in detail
- Data hub implementation — the 60-day approach, step by step
- Data Governance — glossary, lineage, quality and stewardship
- Data Integration track — ELT, streaming, CDC and lakehouse, taught properly
See it on your own data
A 30-minute live demo, using your sources — not a slide deck.
Frequently asked questions
What is the difference between a data hub and a data lakehouse?
A data lakehouse is a storage decision: open table formats bring transactions and schema enforcement to lake storage so one copy serves BI and machine learning. A data hub is a meaning decision: it guarantees that an entity resolves to one identity across every system, that each metric has one definition, and that any figure traces back to its source record. A lakehouse gives you an excellent place to put both the CRM customer ID and the billing account number; it has no opinion on whether they are the same company.
What is the difference between a data hub and a data fabric?
A hub is a place where meaning is resolved and governed. A fabric is a property of the whole estate — uniform access, policy and automation across many systems. In practice a hub is often how a fabric gets built, because shared meaning has to be established somewhere before it can be enforced everywhere.
How do I know which pattern my problem needs?
Match the sentence to the pattern. Slow reports on agreed numbers is a storage problem — warehouse or lakehouse. Finance, operations and sales arriving with three different numbers is a meaning problem — a data hub, and no amount of storage will fix it. Inability to enforce one access policy across a dozen platforms is a fabric problem. A central data team that has become a two-quarter queue is an operating-model problem — data mesh, if the domains can carry it.
Do these patterns compete with each other?
Mostly they combine. A realistic end state is a lakehouse holding the analytical bulk, a hub supplying governed meaning across it and the systems that were never consolidated into it, fabric-like policy enforcement across both, and mesh-style domain ownership wherever domains are strong enough to carry it.