Data Space or Data Lake: Why Sharing Isn't the Same as Centralizing
When an organization decides to invest in a new data architecture, the conversation often starts and ends in the same place: "we need a data lake." And in many cases that makes sense, but in others it hides an underlying confusion that's worth clearing up before writing a single line of code: centralizing data within an organization and sharing data between organizations are different problems, and they require different architectures. The data space vs. data lake debate isn't a matter of technology trends, but of what each tool is actually for.
A data lake solves the problem of having all of a company's information in one place, accessible and analyzable, very well. But the moment that company needs to share part of that data with a supplier, a client, or an administration — while keeping control over who accesses it, what they access, and for how long — the data lake stops being enough. Not because it's bad technology, but because it wasn't designed for that.
In this article, we go over the real differences between a data space and a data lake, what role data mesh plays in this conversation, and how to know which of these architectures suits your organization — or whether you need both working together.
What a Data Lake Is and What It's Really For
A data lake is a centralized repository where an organization stores large volumes of structured and unstructured data from its various internal systems: ERP, CRM, sensors, application logs, files of all kinds. Its great advantage is that it allows raw data to be stored without needing to define its final structure in advance, applying different analyses later depending on the needs of the moment.
A data warehouse is a close relative, more structured: it stores data that's already processed and organized for specific analytical queries, usually business-related. Both share an underlying trait: they're designed for a single organization to centralize and exploit its own internal data.
This makes them excellent tools for internal analysis, business intelligence, or training models with proprietary data. But they don't natively include mechanisms for an external third party to access a specific part of that data under negotiated conditions, to verify who that third party was, or to keep a record of the terms under which the access took place.
What a Data Space Is and How It Differs
A data space isn't a storage repository — it's an exchange infrastructure. Its function isn't to store an organization's data, but to allow different organizations to share data with each other while each retains control over its own.
This difference translates into components very different from those of a data lake:
- A connector that securely authenticates each participant before allowing any transfer.
- A policy engine that automatically decides who can access which data, for what purpose, and for how long.
- A federated catalogue, where each organization publishes what data it offers without needing to move or copy it from its source system.
- Traceability and agreement-recording mechanisms, which keep a verifiable record of every exchange carried out.
In a modern data space, for example, data doesn't have to leave each participant's source systems until the exact moment a specific transfer is authorized and executed. The data stays under the control of whoever generates it; what's shared is access, under explicit conditions — not an uncontrolled copy.
The Problems a Data Lake Doesn't Solve
Centralizing data from several organizations into a single shared data lake may seem, at first glance, like a quick way to collaborate. In practice, it tends to create three problems that a data space avoids by design.
Data sovereignty. When several participants dump their information into a shared repository managed by a third party, they lose direct control over that data: who uses it afterward, for what purpose, or whether it's combined with other sources without their knowledge. A data space preserves that sovereignty because data is shared under conditions defined by its owner, not by whoever manages the repository.
Trust between participants. A data lake doesn't, by itself, solve how to know that the organization requesting access is who it claims to be, or how to verify that it complies with the agreed conditions. A data space includes identity mechanisms and verifiable credentials that confirm each participant's identity before authorizing any exchange.
Granular governance. In a shared data lake, access policies tend to be general and hard to adjust case by case. A data space, through a policy engine such as Open Policy Agent, allows specific access rules to be defined for each dataset and each requester, without relying on generic all-or-nothing access. This is especially valuable when different levels of sensitivity coexist: the same organization can offer an aggregated dataset openly while, at the same time, restricting access to disaggregated data to a small number of verified partners — a distinction a traditional data lake doesn't make by design.
Consider two agricultural cooperatives in Castile and León that want to share crop yield data with an analytics company to improve their forecasts. If they dump all their historical information into a shared data lake managed by a third party, they lose visibility over what happens to that data afterward. If instead they use a data space, each cooperative decides exactly which dataset it shares, with which company, and under what conditions, without giving up control over the rest of its information.
What Data Mesh Brings to This Conversation
Data mesh introduces an interesting middle-ground idea: instead of centralizing all of an organization's data with a single team or platform, it proposes that each business domain (sales, production, logistics) be responsible for its own data and offer it as a well-documented data product to the rest of the organization.
This decentralized philosophy has points in common with a data space: both reject the idea that all information must pass through a single central repository to be useful. The difference is one of scope. Data mesh organizes decentralization within a single organization, across its different departments. A data space organizes decentralization between different organizations, which don't even share the same corporate structure or the same systems.
In fact, both architectures can coexist: a company can apply data mesh principles internally to organize its data domains, while also participating in a data space to share certain data products with external suppliers, clients, or administrations.
When Each Architecture Makes Sense
It's not about choosing one architecture over the other, but about identifying which problem you're trying to solve:
- If the goal is to analyze and exploit an organization's internal data, a data lake or data warehouse is still the right tool.
- If the goal is to share data with third parties while maintaining control, traceability, and access conditions, a data space is the infrastructure that solves that problem.
- If the organization is large and wants to decentralize responsibility for its internal data by business domain, the data mesh approach brings order without requiring a data space.
In practice, many organizations need both: a well-managed data lake can be precisely the source from which a data space offers certain datasets, in a controlled way, to authorized third parties. One organizes the data on the inside; the other manages its release to the outside.
Find the Right Architecture for Sharing Your Data
If your organization already has internal data analysis under control but needs to share information with suppliers, clients, or administrations without losing control over it, a data space is probably the missing piece. A modern data space is designed precisely for that scenario: sharing without centralizing and without giving up sovereignty.
If you want to assess how this architecture fits with your current systems, look for a technology partner with experience in data spaces who can help you analyze your specific case.