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 and Apache Iceberg make this possible.
For example, a company might keep its data as Parquet files in a cloud storage bucket, organized as Delta 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 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, 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, DuckLake and 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 is the usual way to organize the tables inside one.
Databricks and Microsoft Fabric are built around lakehouses, and 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 for how its layers are usually organized.