The Lakehouse in Fabric is designed to merge the strengths of data lakes and data warehouses. It provides scalable storage for diverse data types—structured, semi-structured, and unstructured—while also offering SQL-based querying, metadata management, schema enforcement, and ACID transactions for reliable analytics. This combination lets you store raw data and curated, optimized data in one place and analyze it efficiently with governance features. So, it best describes a system that combines data warehousing and data lake capabilities. It’s not limited to unstructured data, not restricted to raw CSV files, and it isn’t just the same as OneLake—the Lakehouse sits on top of storage like OneLake to enable analytics.

In Fabric, a lakehouse table is a Delta Lake format table stored on OneLake. Delta Lake provides a transaction log and ACID guarantees on top of the data lake, giving you reliable schema enforcement, atomic commits, and features like time travel and concurrent reads/writes. Storing the table on OneLake means the Delta files and metadata live in Fabric’s unified storage layer, making the data accessible and governable across tools and pipelines. Data stored as JSON or CSV lacks the Delta Lake transaction log and schema enforcement, so those formats don’t offer the same lakehouse capabilities.

Access evaluation starts with proving who you are, then deciding what you’re allowed to do, and finally enforcing protections on the data you access. First, Microsoft Entra ID authentication establishes the user’s identity. Without a verified identity, you can’t reliably determine permissions. Next, Fabric access checks evaluate whether that authenticated user has the required rights to access the particular Fabric resources (workspaces, datasets, pipelines) they’re requesting. Only after access is allowed do data security policies come into play, applying data-level protections such as masking, encryption, or other safeguards to ensure the data remains protected according to policy. Approaches that try to apply access or security before identifying the user don’t make sense, so the correct sequence is: authenticate, then verify Fabric access, then enforce data security.

OneLake uses access control lists attached to folders and datasets to manage who can view or modify data. By assigning read and write permissions to specific users or groups on those resources, you implement precise access rights. Following the least-privilege principle means granting only the minimum permissions each user needs to do their job, reducing risk. Keeping an audit trail of permission changes and data-access events helps you verify compliance and detect unusual activity. This approach is preferable because ACLs are explicit and flexible, allowing both read and write rights as needed, and they can be adjusted by authorized admins. They aren’t automatically fixed, they aren’t limited to read-only, and they aren’t deprecated in favor of a single, blanket role model—RBAC and ACLs can work together to provide both broad and fine-grained access control.