Azure’s storage naming history is genuinely confusing. There was Azure Data Lake Store (now commonly called Gen1), plain Azure Blob Storage, and then Azure Data Lake Storage Gen2 – which isn’t a new standalone service at all, but a set of capabilities added on top of Blob Storage. If you’ve found this confusing, you’re not missing something obvious; the naming itself doesn’t do a great job explaining the relationship.
This post clears that up: what ADLS Gen2 actually is, what specifically changed from Gen1 and plain Blob Storage, and why that change turned out to matter so much for how Azure data lakes and lakehouses get built today. For context on how ADLS Gen2 fits into a broader Azure data lake architecture, our earlier piece on Azure data lake architecture and core capabilities covers the full picture.
If you’re planning or troubleshooting an Azure-based data lake right now, our Data Lake Services team at Algoscale works with ADLS Gen2 regularly across client architectures.
A Brief History: Blob Storage, Gen1, and Gen2
Azure Blob Storage has always been Azure’s general-purpose object storage – cheap, scalable, and built for storing files, but organized as a flat namespace under the hood, even when it displays folder-like paths in the console.
Azure Data Lake Store (Gen1) launched as a separate, standalone service purpose-built for big data analytics, with a true hierarchical file system and Hadoop-compatible interfaces. It solved real problems but existed as its own distinct product, separate from Blob Storage, with its own pricing, its own limitations, and its own integration quirks.
Azure Data Lake Storage Gen2 took a different approach: rather than maintaining Gen1 as a separate product, Microsoft added Gen1’s key capability – a hierarchical namespace – directly onto Blob Storage itself. The result is a single storage service that behaves like a data lake when you need it to and like standard object storage when you don’t, without maintaining two separate systems.
What Actually Changed in Gen2
Hierarchical Namespace
This is the change that matters most. With the hierarchical namespace enabled, ADLS Gen2 organizes objects into an actual directory tree – not just path-like naming conventions layered over flat storage. This sounds like a small distinction, but it has real performance consequences covered below.
One Unified Storage Account
Gen2 isn’t a separate account type from Blob Storage – it’s a Blob Storage account with the hierarchical namespace feature enabled. This means the same account can be accessed through both the Blob API and the Data Lake Storage API, depending on what a given tool or application expects.
POSIX-Compliant Access Control Lists
Gen2 supports POSIX-style ACLs at the file and directory level, layered on top of Azure’s standard RBAC. This gives much more granular control than Blob Storage’s container-level permission model alone, which matters significantly once multiple teams share the same storage account.
Atomic Directory Operations
Because Gen2 has a real directory structure, renaming or deleting a folder is a single, fast metadata operation – not a file-by-file rewrite across potentially thousands of objects, which is what a rename effectively requires on flat blob storage with path-style naming.
Multi-Protocol Access
The same underlying data can be accessed through the Blob REST API, the Data Lake Storage REST API, and NFS 3.0 protocol support, depending on your tooling. This flexibility means you’re not locked into a single access pattern as your architecture evolves.
Consistent Pricing and Storage Tiers
Gen2 uses the same hot, cool, and archive storage tiers as standard Blob Storage, with lifecycle management policies working the same way. Unlike Gen1, which had its own separate pricing structure, Gen2 pricing is just Blob Storage pricing with the hierarchical namespace feature enabled.
Why the Hierarchical Namespace Matters So Much
On flat object storage, a “folder” is really just a naming convention – a path like raw/orders/2026/ isn’t an actual directory, it’s a common prefix shared by many independently-named objects. This works fine for simple storage, but it creates real problems for big data workloads:
Directory renames become expensive at scale. Renaming a “folder” on flat storage means rewriting every object whose name starts with that prefix – potentially thousands of operations for what should be one instant change. On Gen2’s real hierarchical namespace, renaming a directory is a single metadata operation regardless of how many files it contains.
Analytics engines perform better with real directories. Spark, Hive, and similar big data engines rely heavily on partition pruning – skipping directories that don’t match a query’s filter conditions. This works far more efficiently against a genuine directory structure than against pattern-matched flat storage paths.
Listing operations are faster and more predictable. Enumerating the contents of a specific directory on Gen2 is a direct, efficient operation. On flat storage, it requires scanning and filtering by prefix, which scales worse as object counts grow into the millions.
A Practical Illustration
Picture a data pipeline that writes daily partitions of event data into a path like events/2026/08/07/. On flat Blob Storage, if that pipeline needs to reprocess and replace an entire day’s data, deleting the old “folder” actually means issuing a delete call for every individual object matching that prefix – potentially thousands of API calls for a single logical operation, with real latency and cost implications at scale.
On ADLS Gen2 with the hierarchical namespace enabled, that same operation is a single directory delete – one metadata change, regardless of whether the directory contains ten files or ten million. This difference compounds across every pipeline in a data lake that regularly reorganizes, reprocesses, or restructures data, which is most of them at any meaningful scale. It’s a genuinely different performance profile, not just a minor optimization.
Where Gen1 Fits Now
Microsoft has been consolidating its data lake storage strategy around Gen2, and Gen1 has been retired as a supported service. If you’re still running workloads on Gen1, migrating to Gen2 is worth prioritizing – not just because of the deprecation itself, but because Gen2 has genuinely superseded Gen1 on nearly every dimension: better tooling integration, unified pricing with Blob Storage, and continued investment from Microsoft, none of which apply to Gen1 anymore.
How Gen2 Enables the Modern Azure Data Stack
Gen2’s hierarchical namespace and multi-protocol access are what allow the rest of Azure’s analytics ecosystem to work together as smoothly as it does. Azure Synapse Analytics, Azure Databricks, and Microsoft Purview all read and write directly against Gen2 storage, treating it as the shared foundation underneath otherwise-separate compute and governance tools.
This same foundation is also what Microsoft Fabric’s OneLake is built on – OneLake is, at its core, a Gen2-based storage layer that spans an entire tenant. Understanding what changed in Gen2 is a genuinely useful context for understanding where Microsoft’s data platform strategy is headed. Our post on why Microsoft Fabric is the future of data warehouse modernization goes deeper into that direction.
For a closer look specifically at OneLake’s relationship to this underlying storage layer, see our post on OneLake and the future of data warehousing.
Best Practices When Working With ADLS Gen2
Enable the hierarchical namespace at account creation, not after. While Microsoft has introduced tooling to enable it on existing accounts, planning for it from the start avoids migration complexity entirely.
Design your directory structure deliberately. Since directories are now a real structural feature rather than a naming convention, invest in a thoughtful hierarchy – by domain, by date, by source system – since it directly affects both query performance and how easily teams can navigate the data.
Use ACLs for fine-grained access, RBAC for broad strokes. Combining Azure RBAC for account and container-level access with POSIX ACLs for specific file and folder permissions gives you both simplicity and precision where each is needed.
Take advantage of lifecycle management policies. Since Gen2 uses standard Blob Storage tiers, the same automated lifecycle rules that control cost on regular Blob Storage apply directly, and are worth setting up from the start rather than after storage costs have already grown.
For guidance on securing this kind of environment more broadly, our post on data lakehouse security best practices for cloud-native organizations covers the governance side in more depth.
Common Migration Considerations
Moving from Blob Storage without the hierarchical namespace enabled, or from Gen1, to a proper Gen2 setup isn’t always a simple flag flip. Existing applications built against flat Blob Storage assumptions may need adjustment, and Gen1-specific tooling or scripts will need updating to target Gen2’s APIs. Planning this migration with the same care as any other data infrastructure change – inventorying dependencies, testing thoroughly, and migrating incrementally where possible – avoids the most common friction points.
Getting Your Azure Storage Foundation Right
Choosing the right storage foundation shapes everything built on top of it – query performance, governance model, and how easily your architecture integrates with the rest of the Azure ecosystem. At Algoscale, our Data Lake Services team has helped organizations both build new ADLS Gen2 architectures from scratch and migrate existing Gen1 or flat Blob Storage setups onto Gen2 without unnecessary disruption.
To see the full range of data engineering and analytics work we do beyond Azure specifically, take a look at what Algoscale builds across the data stack.
Why Algoscale
● Pre-built accelerators. We don’t start every engagement from a blank slate – proprietary accelerators built from prior implementations speed up common data source integration and analytics patterns.
● Faster time to value. For a focused initial scope covering core data sources and first analytics use cases, our accelerators typically compress development timelines to around four weeks, rather than the several months a from-scratch build often takes.
● Built on a scalable framework. Our implementation approach follows a repeatable, scale-ready framework, so the architecture built for your first use case extends cleanly as data volume and teams grow, rather than requiring a redo.
● Microsoft Solution Partner for Data & AI. Algoscale holds Microsoft Solution Partner status for Data & AI, including specific expertise implementing Microsoft Fabric as a modern data warehouse.
Frequently Asked Questions
1. Is ADLS Gen2 a separate service from Azure Blob Storage?
No. Gen2 is Blob Storage with the hierarchical namespace feature enabled, along with additional capabilities like POSIX ACLs and multi-protocol access. It’s not a separate storage account type with independent pricing or infrastructure.
2. Can I enable the hierarchical namespace on an existing Blob Storage account?
Microsoft has introduced tooling to upgrade certain existing accounts, but it’s not universally available for every account configuration, and it involves real planning. For new projects, enabling it at account creation avoids this complexity entirely.
3. Is Gen1 still usable, or has it been fully retired?
Microsoft has retired Gen1 as a supported service. Any workloads still running on Gen1 should prioritize migration to Gen2, both because of the deprecation and because Gen2 offers meaningfully better performance, tooling, and integration.
4. Does using Gen2 cost more than plain Blob Storage?
Gen2 uses the same underlying storage tiers and pricing model as Blob Storage – there’s no separate, higher pricing tier for having the hierarchical namespace enabled. Costs are driven by the same factors (storage volume, tier, and transaction counts) as standard Blob Storage.
5. Do I need Gen2 if I’m only using Azure for simple file storage, not analytics?
Probably not. The hierarchical namespace’s main benefits – faster directory operations, better analytics engine performance – matter most for big data and analytics workloads. For simple file storage without those requirements, standard Blob Storage without the hierarchical namespace is perfectly adequate and slightly simpler to manage.
6. How does Gen2 relate to Microsoft Fabric and OneLake?
OneLake, part of Microsoft Fabric, is built directly on ADLS Gen2 as its underlying storage layer, extended to work as a single logical data lake across an entire tenant. Understanding Gen2 is genuinely useful groundwork for understanding how Fabric and OneLake work underneath their higher-level abstractions.
