Azure Data Lake Storage: product and architecture
Our verdict up front: Azure Data Lake Storage (ADLS) is the right default storage layer if your analytics stack already lives in Azure and your identity model runs on Microsoft Entra ID, and a poor fit if you want a ready query engine or a cloud-neutral foundation. This Azure Data Lake Storage review treats the product as what it is: object storage with a hierarchical namespace on top of Azure Blob Storage, not a pipeline tool, warehouse or compute platform. Azure's retail price list for East US prices stored data from $0.021 per GB per month (Hot LRS, first 50 TB) to $0.00099 per GB per month (Archive LRS).
Overview
Microsoft positions ADLS as a "massively scalable and secure data lake for your high-performance analytics workloads." The pitch is consolidation: land ingestion, processing and visualization on one storage platform instead of many per-team buckets and file shares. ADLS is fully integrated with Azure Blob Storage, so Blob features such as Entra ID integration, encryption at rest, lifecycle policy management and storage account firewalls apply to it.
Microsoft also markets an on-ramp for organizations leaving on-premises Hadoop, the WANDisco LiveData Platform for Azure, for migrating HDFS-based lakes. That tells you who the product is for: enterprises with large file-oriented data estates rather than startups picking a first warehouse.
Our dataset holds no GitHub metrics, user review scores or customer counts for this closed-source managed service. We evaluated it from Microsoft's product and pricing pages and Azure's retail price list, checked on 5 October 2026, so judge it on architecture, price mechanics and your existing Azure commitment.
Key Features and Architecture
ADLS is a capability layer on Azure's object storage, not a separate storage engine. It inherits Blob Storage's tiering, lifecycle and replication machinery and adds file system semantics.
Hierarchical namespace (HNS). Directories are real objects, so renaming or deleting a directory is one atomic metadata operation instead of N copy-and-delete operations across every file under it. Microsoft's FAQ uses the case that matters most: Spark and Hive jobs write output to a temporary directory and rename it on commit. HNS also enables POSIX-compliant access control lists (ACLs) that propagate permissions from parent directories, which is how most Hadoop permission models are reproduced.
Layered security. Entra ID authentication, Azure role-based access control (RBAC) at account and container scope, attribute-based access control (ABAC) conditions and POSIX ACLs on paths, plus network-level control and advanced threat protection. Microsoft states it has 34,000 full-time-equivalent security engineers and more than 100 compliance certifications, over 50 of them specific to regions and countries.
Durability and redundancy. Microsoft states 16 9s of data durability with automatic geo-replication. Redundancy is chosen per account (LRS, ZRS, GRS, RA-GRS, GZRS or RA-GZRS), and the choice changes the per-GB rate.
Tiering and lifecycle policies. Tiering applies per object, and lifecycle policies automate moves, for example aging Parquet partitions older than 90 days from Hot to Cool and later to Archive. With reservations, this is the main cost lever you control.
Separate storage and compute. Storage and compute scale and bill separately. ADLS has no query layer of its own; it serves Hadoop-compatible engines such as Spark and Presto through the ABFS driver, and in Azure it works with Data Factory, HDInsight, Databricks, Synapse Analytics and Power BI.
Ideal Use Cases
Hadoop migration in a regulated enterprise. A bank or insurer with a large on-premises HDFS cluster, a platform team of 8 to 20 engineers and a hard requirement to keep directory-level ACLs and job semantics. HNS reproduces the file system behavior those jobs assume, and WANDisco LiveData Platform for Azure exists to move the data.
Multi-engine lakehouse for a mid-size Azure shop. A data team of 10 to 30 people with Databricks or Synapse doing transformation and Power BI serving business users. The payoff is governance: one Entra ID identity plane, RBAC plus ABAC conditions and one set of network rules instead of per-tool credentials.
Long-retention archives. IoT, clinical research and log data that must be kept for years but is rarely read fits Cold ($0.0036 per GB per month on LRS in East US) and Archive ($0.00099 per GB per month on LRS), moved there by lifecycle rules.
Don't use this if your team is small, has no platform engineer and wants to run SQL on day one. ADLS gives you durable storage and an access model, but no catalog, table format, query engine or semantic layer. Also avoid it as your main lake if your compute is spread across AWS and Google Cloud on purpose: the Entra ID-centered security model is where the lock-in lives.
Strengths & Trade-offs
Pros
- Atomic directory operations. Directory rename and delete are single metadata operations, which removes the per-object rename loop Spark and Hive commits run on flat object stores.
- Four tiers with automation. Lifecycle policies can age data from Hot ($0.021 per GB per month on LRS) to Archive ($0.00099) without a maintenance job.
- Layered access control. Entra ID, RBAC, ABAC, POSIX ACLs and network rules can express "this service principal, from this network, on this path prefix".
- Published durability and compliance. Stated 16 9s durability and more than 100 certifications give a risk committee concrete items to check.
Cons
- Storage only. No query engine, table format, catalog or transformation layer; Synapse, Databricks or Data Factory are separate purchases, so a lakehouse on ADLS never costs just the per-GB rate.
- Archive is not readable in place. Data must be rehydrated to an online tier first, which adds delay and charges, and over-eager lifecycle rules become a problem when an auditor asks for old data.
- Operations costs are hard to see up front. For small-file or high-churn workloads they are the main unknown, and only your own workload profile resolves it.
- Entra ID is the lock-in. The storage API is portable; the RBAC, ABAC and ACL model built on it is not, so leaving Azure means rebuilding authorization, not only copying files.
