# Lakehouse

> A lakehouse stores data as open files in object storage and adds warehouse features: schemas, transactions, updates, deletes and governance.

A lakehouse stores data as open files in cheap object storage, like a data lake, and adds the features of a warehouse: tables with schemas, transactions, updates and deletes, and governance. Open table formats such as [Delta Lake](https://emolysis.com/glossary/delta-lake) and [Apache Iceberg](https://emolysis.com/glossary/iceberg) make this possible.

For example, a company might keep its data as Parquet files in a cloud storage bucket, organized as [Delta](https://emolysis.com/glossary/delta-lake) tables. Data engineers write to those tables with Spark jobs, analysts query them with SQL, data scientists read the same tables into notebooks, and a BI tool reads [gold](https://emolysis.com/glossary/gold-layer) tables through a SQL endpoint. There is one copy of the data, governed by one catalog, instead of a data lake for raw files plus a separate warehouse holding a loaded copy.

The table format is what turns a folder of files into a table: it records which files make up each version, so writes are atomic and readers see consistent snapshots. A catalog on top, such as [Unity Catalog](https://emolysis.com/glossary/unity-catalog), adds names, permissions and lineage. Compute is separate from storage, so different engines and clusters can work on the same tables and scale on their own.

A lakehouse still needs the habits of a warehouse: schemas that are enforced, tests on the data and clear layers. Without them it becomes a data lake again, with many files and little trust in any of them. See also [OneLake](https://emolysis.com/glossary/onelake), [DuckLake](https://emolysis.com/glossary/ducklake) and [bronze layer](https://emolysis.com/glossary/bronze-layer).

A practical test of a lakehouse is whether two different engines can read the same table and get the same answer, and whether a failed write leaves the table as it was. Both depend on the table format and the catalog, not on the storage underneath. The [medallion architecture](https://emolysis.com/glossary/medallion-architecture) is the usual way to organize the tables inside one.

[Databricks](https://emolysis.com/platforms/databricks) and [Microsoft Fabric](https://emolysis.com/platforms/microsoft-fabric) are built around lakehouses, and [Snowflake](https://emolysis.com/platforms/snowflake) supports Iceberg tables. Emolysis writes for your platform's lakehouse and keeps a small local one per project for development. See the [medallion architecture](https://emolysis.com/glossary/medallion-architecture) for how its layers are usually organized.

---

Page: https://emolysis.com/glossary/lakehouse. Emolysis is a product of Bandpey GmbH, Munich, Germany. It is in private development, and nothing is released yet.