“We just finished building a data warehouse… and now we’re starting a data lake.”
But why?
A data warehouse and a data lake serve similar goals, yet they solve them in very different ways.
In this article, we’ll explore the differences between the two and the technology behind each approach.
The concept of a data warehouse originated as far back as the 1980s. In the early 1990s, Bill Inmon and Ralph Kimball described how transactional systems are mainly built to support daily processes, while companies want to use data for reporting, analysis, and insights.
Around 2011, Big Data emerged and the concept of a data lake gained popularity. Later, this evolved further into the data lakehouse: a technical architecture that combines the flexibility of a data lake with the structure and performance of a data warehouse.
A transactional system is, for example, your CRM system: it supports the day-to-day management of customer data. Your ERP system is also a transactional system, helping you manage resources and business processes. The same applies to your website and accounting software. In fact, any system used to capture and process data is considered a transactional system.
Typically, transactional systems contain a significant amount of business logic, provide a user-friendly interface, and rely on a relational database. These databases are commonly referred to as OLTP (Online Transaction Processing) databases.
A data warehouse, on the other hand, is a central repository designed to store and analyze structured data. By structured data, we mean data organized in tables, such as databases, CSV files, or Excel spreadsheets, in other words, data collected from multiple transactional systems.
A data warehouse operates according to a predefined schema: an agreed-upon structure that determines how data is organized and related. It typically contains the logic required to transform raw data into meaningful insights, which are then visualized through business intelligence tools. The underlying database is an OLAP (Online Analytical Processing) database, and the term “data warehouse” is often used interchangeably with an OLAP database.
However, a data warehouse is much more than a traditional database. It is specifically designed to provide fast and accurate answers to analytical questions, whether for recurring reports or ad hoc analyses, without placing a heavy load on operational source systems.
In addition, a data warehouse serves as a foundation for connecting and consolidating information across the organization into a business-friendly data model. This creates a 360-degree view of the entire business, enabling users to understand relationships and gain insights across departments and processes. Think of it as a central hub that makes digital information easier to interpret, explore, and use for decision-making.
While transactional systems are primarily designed to support day-to-day business operations, a data warehouse is built to enable analysis and generate insights.
The primary role of a data warehouse is to bring data from different systems together into a single centralized environment. This enables analysis across the entire organization. It also serves to store and maintain historical data. Think of questions like: “What have our sales figures been per month since 2022 for product A?” or “Which process in our organization is the least efficient?” Without a data warehouse, this kind of information is often scattered across multiple applications, making analysis slow, error-prone, or even impossible.
As an organization grows, multiple transactional systems are inevitably required. There is no such thing as a silver bullet, and the idea that “one software system should do everything” does not hold up at scale.
For an SME, having a central place for data, KPIs, and definitions is the foundation of becoming data-driven.
*Note for completeness: in larger organizations, this responsibility is sometimes distributed (see also data mesh).
Until about ten years ago, most data warehouses ran on a single powerful server. However, such systems had to stay permanently active, even when no one was running any analyses. In addition, storage and compute power were tightly coupled: if you needed more data capacity or more complex analyses, you had to invest in additional processing power—even if it was only needed occasionally.
Around the same time, the shift to the cloud began. Organizations no longer wanted to invest in large on-premise servers, as this was often inefficient and inflexible.
In 2011, the term “Big Data” first gained widespread use. Companies started collecting massive volumes of data: terabytes and even petabytes of structured data, logs, sensor data, clickstreams, images, and many other sources. These volumes quickly became too large to process efficiently on a single system.
This triggered a fundamental shift in system architecture. It became necessary to decouple storage from compute. Data could be stored cheaply in scalable storage systems, while processing power could be added only when needed. Instead of relying on one powerful machine, organizations began using clusters of computers working together to process large datasets. In other words, not only storage became horizontally scalable, but compute as well (horizontal scaling means adding more machines to share the workload instead of relying on a single powerful machine).
From this evolution, the data lake emerged: a flexible storage layer where large volumes of raw data are centrally collected, while compute resources can be allocated independently and on demand. This means you only use the processing power you need, exactly when you need it.
A data lake is a central storage system for large volumes of data in many different formats. In technical terms, it is typically an object storage system organized into “buckets”. You can think of it as a large container or reservoir of information.
Unlike a data warehouse, which primarily works with structured, tabular data, a data lake can store almost any type of file: CSVs, Excel files, database dumps, PDFs, images, videos, log files, and even raw binary data. It can be compared to a massive network drive where all data is stored centrally, while access and security are managed through APIs.
Like a data warehouse, a data lake aims to make data centrally available for analysis and insights. The key difference lies in the architecture: storage and compute are completely decoupled.
The rise of data lakes made it possible for organizations to store data at very low cost. However, this also led to widespread overuse because if storage is easy and cheap, everything gets stored. As the saying goes: “With great power comes great responsibility.” This freedom had a downside: huge volumes of data with very little structure. Many companies ended up creating a “data swamp” instead of a data lake, a disorganized pile of raw, hard-to-use data.
In addition, operational challenges emerged: how should new data be handled? How should historical data be managed? How do you define ownership and security? These were often built into traditional databases and data warehouses, but became less clear once systems were decoupled. Addressing these issues has become an active area of development for data lake technologies.
A data lake is therefore especially useful when you need flexibility, want to work with large and diverse datasets, and aim to run analyses at scales that were previously not feasible. However, without strong governance and structure, that flexibility can quickly turn into chaos.
Examples of data lakes include:
Around 2019, a new evolution emerged: the data lakehouse. The big technology companies behind data lakes noticed that organizations needed more structure and reliability on top of their flexible data lakes.
A data lakehouse therefore combines the best of both worlds:
In practice, this means that you can still store data cheaply and at scale in a data lake, while at the same time adding extra layers that enforce structure. Think of fixed schemas, quality checks, version control, and parallel queries for reporting and analysis.
Examples of a data lakehouse:
The discussion of “data warehouse versus data lake” is actually not about which technology is better. It is about which architecture best fits your organization, your data, and your needs.
Data lakes emerged because classic data warehouses started to struggle with the rise of big data: large volumes, high processing speeds, and a greater variety of data sources. By decoupling storage and computing power from each other, data storage became much cheaper and more flexible. However, that flexibility came with a downside: without enough structure, messy and disorganized data lakes often appeared. That is why a pure data lake is rarely the best choice today.
The data lakehouse combines the scalability and flexibility of a data lake with the structure, reliability, and analytical capabilities of a data warehouse. Many modern data platforms and data infrastructures are therefore evolving more and more toward a lakehouse architecture.
A data warehouse remains a strong choice for organizations that mainly work with structured data and that want to perform fast and reliable analyses. It offers structure, performance, and simplicity. For many SMEs, that is still more than enough today.
Moreover, modern data warehouses have become much more flexible than they used to be. They can read data from and write data to data lakes, which makes them fit perfectly within today’s data architectures. The line between a data warehouse and a data lakehouse is becoming increasingly blurred. In fact, many modern data warehouses already have lakehouse functionalities today without users even being aware of it.
But what do you actually need?
Not every company has petabytes of data, AI models, or complex video files. For many organizations, a well-built data warehouse or lakehouse is still the best solution. It offers the structure, simplicity, and reliability needed to quickly get value out of data. As the amount of data, the number of data sources, and the analytical ambitions grow, the scalability and flexibility of a lakehouse architecture become more important. For larger organizations, that can be a decisive advantage.
So the best choice is not automatically the newest technology, but the solution that fits the maturity, scale, and ambitions of your organization.
With MAKO, we deliberately choose a modern open data warehouse/lakehouse approach with ClickHouse. Why? Because it is fast, works perfectly for structured data, and matches the reality of most SMEs. We can easily scale up to a full lakehouse architecture. On top of that, we provide a strong data security model within the same software, which gives everyone in the organization the chance to work in a data-driven way.
And what if your organization or needs change later on? No problem. MAKO and Understanding Data are designed to evolve flexibly along with new technologies and future data architectures, including data lake and lakehouse models.
Would you like to know more about how MAKO is the data foundation for SMEs?
