Hi, it’s Kote from Tower’s customer success team. In my last post, I explored the murky world of data lakes, lakehouses, and data warehouses. I also promised to dive a little deeper into why someone may pick a data lakehouse over a warehouse or a lake, which is the purpose of this post. It’ll be a little more theory-driven, with reasoning regarding what an organization may be looking for and what needs may need to be fulfilled.
But, before we get into that, let’s get a quick reminder on how a data lakehouse is different from a data warehouse vs a data lake.
Data Lakehouse vs Data Warehouse vs Data Lake: Key Differences
The table below captures the core characteristics and differences of data lakehouses, data warehouses, and data lakes.
Aspect | Data Warehouse | Data Lake | Data Lakehouse |
Data Types | Primarily structured data (tables, rows, columns) | All data types (structured, semi-structured, unstructured) | All data types (structured to unstructured, in one system) |
When is schema applied to records? | Schema-on-write – define schema before loading data. Ensures consistent, clean data upfront. | Schema-on-read – store raw data without predefined schema; define structure when reading. Very flexible, but data may be messy until read. | Hybrid – can ingest raw data (like schema-on-read) but enforce schema when needed. Supports schema evolution and metadata to provide structure and reliability. |
Storage Technology | Typically proprietary or specialized high-performance storage (often tightly coupled to the warehouse vendor). | Cheap, scalable object storage (e.g., AWS S3, Hadoop HDFS) to hold raw files. | Object storage (same as a data lake) with an added table format layer (e.g., Apache Iceberg, Delta Lake) for structure. Combines low-cost storage with a structured layer on top. |
Performance | Optimized for fast SQL queries and BI analytics on structured data (indexes, MPP databases, etc.). | Raw storage is not optimized for speed; querying large raw files can be slower without specialized processing engines. | Designed for high performance analytics on big data. Indexes and query optimizations give near-warehouse speeds, even as it handles diverse data types. |
Data Governance | Strong governance – data is cleaned and quality-checked before entry; robust access controls and auditing. | Limited built-in governance – must be added via external tools; risk of a “data swamp” if data is not managed (quality varies). | Built-in governance – uses metadata catalogs and ACID transactions for reliability. Enables data versioning, fine-grained access control, and prevents chaos by keeping data organized. |
Use Case Focus | Business Intelligence & Reporting – ideal for dashboards, reporting on historical trends with trusted data. | Data Science & Exploration – ideal for storing huge raw datasets, exploratory analytics, machine learning, streaming data. | Unified Analytics & AI – one platform for BI and ML/AI. Enables both traditional reporting and advanced analytics on the same data, without needing to move between systems. |
In short, data warehouses are great for structure, speed, and reliable analytics when data is well organized. Data lakes are flexible and can store anything at a low cost, but they can get messy and need more effort to manage. Data lakehouses try to combine the best of both, offering the flexibility of a lake along with the performance and control of a warehouse.
In practical terms, when you’re deciding between a data lakehouse and a data warehouse, think about what your workloads need. A data warehouse is a good fit if all your data is tabular and you want fast, consistent reports, such as for financial data. Warehouses can struggle if you suddenly need to work with unstructured data or try new types of analytics. If you compare a data lakehouse to a data lake, the lakehouse helps solve the lake’s problems with governance and speed. It makes your data more useful for analytics by adding structure and reliability to the raw data.
Should you use a data lakehouse, a data lake, or a data warehouse?
Great question. I have a terrible answer: it depends. What are your requirements? How much data are you storing? Is it structured, semi-structured, or unstructured? Do you want a table abstraction layer for your data? Do you need the same data for both data analytics and ML use cases?
Right now, data lakehouse architecture is complex, but it brings together the best features of all three options. It’s the newest approach, and like most new things, it’s getting a lot of attention from people who want to be on the cutting edge. However, I’d suggest not making your decision based solely on the hype. Consider why there is so much excitement around it from market leaders and innovators. I mean, the Tower team even built our own data lakehouse to analyze product metrics.
Data lakehouses provide a single place to store all your analytical and ML data. This means no more separation between BI data (e.g., in Snowflake) and ML data (e.g., in Databricks), and no more expensive ETL compute to move things between the two.
Simpler joining of all your data. Having both structured and unstructured data in one place allows your teams to join them more easily and learn novel insights.
They are cost-efficient. Storing data in open formats on cheap cloud object storage and using compute only when needed (thanks to decoupled storage & compute) can be more cost-effective for large data volumes than keeping everything in an expensive legacy data warehouse.
They have significant industry momentum. Industry leaders like Microsoft, Snowflake, Databricks, and others are embracing it. In the last couple of years, cloud and data platform vendors have begun adding lakehouse-like capabilities. For example, AWS announced a feature to query data in S3 with a warehouse-like experience (Iceberg tables on S3), and Snowflake introduced support for open table formats (Iceberg) through its new Open Catalog.
But is a data lakehouse the right choice for you, now?
If your main goal is to store unstructured data for a while and use it only years later, a data lake is all you need.
If you need to analyze data for BI purposes, you will need a data warehouse.
If you are building something that will store structured and/or semi-structured data, and want to have the benefits of a table-like interface and use SQL and Python tools to query this data, then you should seriously consider getting yourself a data lakehouse.
There is more nuance to this decision, and this post is already quite extensive. In part 3 of this series, I will ask some experts for their take on this topic.
We, at Tower, have been working with data lakehouses a lot. We’ve even built an internal lakehouse to better analyse our product usage. We frequently write on lakehouse topics, e.g., on how to get a GUI for an Iceberg Lakehouse. Have a read about some of these topics, and if you ever wanted to give lakehouses a try, consider signing up for our Free plan.