When a company decides to organize its data to make better decisions, the same dilemma almost always appears: a data lake or a data warehouse? Both are ways to centralize information for analysis, both live comfortably in the cloud, and both promise “a single source of truth.” The difference is not about which is better, but about which problem each one solves — and choosing without criteria is paid for later in cost, in response time, or in a data project that never quite delivers value.
This guide compares both options with decision criteria for technology leaders, not just data architects.
What each one is, in one sentence
- A data warehouse is a repository of already structured and cleaned data, designed to answer known business questions with fast SQL queries: sales by region, margins by product, dashboard metrics. It defines the structure before storing the data. On AWS, that service is Amazon Redshift.
- A data lake is a repository that stores data in its original format —tables, files, logs, sensor data, text, images— without requiring a predefined structure. It applies structure only when someone reads the data. On AWS, it is typically built on Amazon S3, with AWS Glue and AWS Lake Formation around it.
The confusion is understandable: both “store data for analysis.” But the order in which they organize the information is different, and that order is what decides.
The criteria that actually decide
1. The type of data you need to store
This criterion filters before any other. If your data is mostly structured and already known —transactions, ERP records, tables from a billing system—, the data warehouse receives it naturally. If you need to store varied, raw data —files of different formats, device data, semi-structured content you don’t yet know how you’ll use—, the data lake was designed exactly for that: it accepts everything without asking you to define the structure in advance.
According to AWS documentation, the data warehouse requires designing the schema before writing the data —a schema-on-write approach—, while the data lake applies the schema on read —schema-on-read—, which gives it the flexibility to support diverse formats.
2. Who is going to use the data
The warehouse is made for the business area and analysts: people who ask known questions in SQL, build reports and live in dashboards. The lake is made for data science and engineering: profiles that explore, train machine learning models and need the raw data, not an already summarized version. Asking who will consume the information —and with what tools— orders the decision faster than any technical comparison.
3. The moment of processing: ETL vs ELT
Here is a concrete operational difference. The warehouse usually requires preparing the data before storing it: it is extracted, transformed and loaded already clean (the ETL pattern). The lake reverses the order: it loads the data first and transforms it only when needed (ELT pattern). This has consequences for cost and time-to-start: the lake lets you begin storing without resolving all the input transformation; the warehouse asks for that work up front, and in exchange delivers faster, more predictable queries.
4. Cost and governance
The object storage on which the data lake lives is inexpensive and grows without over-provisioning, which makes it attractive for storing large volumes of data that don’t yet produce direct value. But that same flexibility carries a known risk: without a catalog, without access control and without quality, a data lake turns into a “data swamp” where no one finds anything reliable. That is why governance —cataloging with AWS Glue, controlling access with AWS Lake Formation— is not optional in a lake. The warehouse, by imposing structure from the start, brings much of that governance built in, in exchange for less flexibility.
Data lake vs data warehouse: the decision table
| Criterion | Data warehouse (Amazon Redshift) | Data lake (Amazon S3 + Glue) |
|---|---|---|
| Data type | Structured and cleaned | Any format, raw |
| Schema | Defined before writing (schema-on-write) | Applied on read (schema-on-read) |
| Processing | ETL: transform before loading | ELT: load and transform later |
| Typical user | Business and analysts (SQL, BI) | Data science and engineering |
| Ideal use | Reporting, dashboards, known queries | Exploration, machine learning, varied data |
| Storage cost | Higher, optimized for querying | Low, scales with usage |
| Governance | Built in structure | Requires explicit catalog and control |
When each one fits
Choose the data warehouse when your urgent need is reliable reporting and management dashboards, when your data is already structured and known, and when query response time matters for daily operations.
Choose the data lake when you need to consolidate scattered data from many sources and formats, when you want to enable data science and machine learning over raw data, or when the volume and variety make structuring everything up front impractical.
The mature answer: don’t choose, combine
In practice, most companies don’t choose one or the other: they combine them. The data lake receives all the raw data at low cost; the data warehouse pulls from it what the business queries daily and serves it fast. That combination has a name —the lakehouse architecture— and it is where modern data design on AWS is heading: Amazon S3 as the storage layer, AWS Glue for cataloging and transformation, and Amazon Redshift able to query lake data without moving it. They are not two separate worlds to choose between; they are two layers of the same platform.
And when you don’t need a Redshift: the serverless lakehouse
Not every company needs a dedicated data warehouse to have reliable business analytics. When the data volume is moderate and queries are not constant —the case for many companies in Latin America—, there is a lighter path that avoids keeping a cluster running: modeling the data directly on the data lake with an open table format like Apache Iceberg, querying it with SQL using Amazon Athena —which is serverless and charges per query, with no infrastructure to manage— and connecting the result to a business viewer like Power BI or Amazon QuickSight.
The pattern, concretely: the data lives in Amazon S3; Iceberg gives it table structure, versioning and transactions —the data model that used to require a warehouse—; Athena runs the SQL queries without spinning up a cluster; and the dashboard feeds from there. It is the same business question answered with fewer pieces running.
At Caleidos we have found this architecture efficient for Latin American clients whose volumes do not yet justify a Redshift: it delivers reliable reporting and dashboards without the fixed cost of a dedicated store. And when the volume grows, queries become constant and sustained performance becomes the priority, Amazon Redshift takes over —and since it also queries Iceberg tables on Amazon S3, the growth path stays open without rebuilding the data model.
How we approach it at Caleidos
At Caleidos, as an AWS Advanced Tier Services Partner, this decision is part of our data and analytics and data engineering practice: we start from the business question, not the tool, we size which layer delivers value first in your case, and we design the architecture so the lake and the warehouse work together rather than compete. If you’d like to understand each piece first, we go deeper into what a data warehouse is, what a data lake is and what Amazon Redshift is.
Organizing your company’s data strategy?
Let’s talk about your case: in 30 minutes we give you a concrete read on whether your starting point is a data warehouse, a data lake, or an architecture that combines both.
