The Supermicro 160-bay NVMe server turns a familiar 4U rack slot into an all-flash storage wall. With 160 hot-swap U.2 bays, one AMD EPYC 9005 processor and enough drive capacity to approach 20PB using 122.88TB SSDs, the ASG-4116S-NU160R pushes storage density into territory that changes the surrounding server design.
The useful question is what happens after the drives are installed: at this scale, density shifts the bottleneck into PCIe topology, networking, cooling, power and failure containment.
Storage Density Is Becoming a Rack-Level Design Decision
Enterprise storage used to scale in a relatively predictable way: more capacity usually meant adding more drives, more enclosures and eventually more racks. Ultra-high-capacity NVMe SSDs are changing that equation by allowing operators to concentrate far more data into the same physical footprint.
That creates an obvious advantage for data centers where rack space is expensive or already constrained. Fewer chassis can potentially support the same raw capacity target, reducing the number of servers, cables and rack positions required to build a large flash tier.
The tradeoff is that capacity density concentrates infrastructure pressure. Power delivery, airflow, PCIe connectivity and network throughput all have to keep pace with the growing number of drives behind a single host. Packing more storage into less space does not remove those limits; it makes them more visible.
This is why the newest high-density storage systems are better understood as engineering exercises rather than capacity records. The challenge is no longer simply fitting more SSDs into a chassis, but designing a server that can service, cool, connect and protect an unusually large amount of flash without creating new bottlenecks.
The Supermicro 160-Bay NVMe Server Is Built Around Density
Supermicro’s 160-bay system specifications confirm a 4U chassis with 160 top-loading, hot-swap 2.5-inch U.2 NVMe bays. Four front E1.S bays and two M.2 slots sit alongside the main drive population, while a single EPYC 9005-series CPU handles the host side.
The default configuration includes three PCIe 5.0 x16 expansion slots, two onboard 10GbE ports and up to 6TB of DDR5 memory. A redundant pair of 2,600W Titanium-level power supplies supports the chassis.
Put a 122.88TB SSD into each U.2 bay and the raw total reaches 19.6608PB before the E1.S devices are counted. Solidigm’s 122.88TB drive specifications position that capacity class for read-intensive AI, data-lake, object-storage and scale-out workloads.

Extreme NVMe Density Changes the Rest of the Server
Once a 4U chassis approaches 20PB of raw flash, the storage media itself stops being the only part of the design that matters. The server has to coordinate hundreds of PCIe links, maintain predictable airflow and move enough data through the network to prevent the drive pool from becoming stranded capacity.
That is where high-density systems become more complicated than their bay count suggests. A server can physically hold 160 NVMe drives, but aggregate performance depends on the internal PCIe topology, switch architecture and how many drives are active at the same time. Capacity and throughput do not scale equally.
Serviceability also becomes more consequential. A failed drive in a conventional server affects a smaller pool of media, while a chassis this dense places far more storage behind one host and one enclosure. Clear drive identification, hot-swap access and fast fault isolation become essential to keeping maintenance from turning into a broader availability problem.
The result is a different kind of storage optimization. Instead of asking only how many terabytes fit into a rack, infrastructure teams have to evaluate how efficiently that capacity can be powered, cooled, protected and accessed. At this level of density, the surrounding architecture determines whether the hardware is genuinely useful.
The design choices are easier to understand together:
| Design element | Published configuration | Infrastructure consequence |
|---|---|---|
| Chassis | 4U rackmount | Very high capacity per rack unit |
| Main storage | 160 U.2 NVMe bays | Large flash pool behind one host |
| U.2 connectivity | PCIe 4.0 x1 per bay | Density favored over full x4 bandwidth |
| Host CPU | Single AMD EPYC 9005 | Fewer host processors for the drive count |
| Expansion | Three PCIe 5.0 x16 slots | Room for higher-speed network or I/O cards |
| Power | Redundant 2,600W supplies | Power and airflow remain major design factors |
The nearly 20PB figure is therefore plausible as raw capacity, but usable capacity will fall after data protection, spare space and storage-software overhead are applied.
PCIe Switching Makes 160 Drives Possible
The most revealing specification is the lane width. Each of the 160 U.2 slots is PCIe 4.0 x1 rather than a full x4 connection, and Supermicro lists a PCIe switch inside the platform.
That is a deliberate engineering trade. Giving 160 drives four dedicated lanes each would require 640 PCIe lanes before networking, boot devices and other I/O entered the equation. Switching and narrower links allow far more SSDs to sit behind a single server node.
The consequence is capacity before peak drive speed. Buyers cannot multiply the maximum sequential throughput of a x4-capable SSD by 160 and treat that as chassis performance. The internal topology and host path place limits on what can move simultaneously.
For data lakes, object stores and some AI repositories, that compromise can make sense. These workloads may value capacity, parallel access and rack efficiency more than maximum bandwidth from every individual drive at once.
Extreme Capacity Creates a Larger Failure Domain
Nearly 20PB of raw media in 4U also changes the impact of a node-level problem. A conventional scale-out design distributes capacity across more servers; this chassis concentrates substantially more data behind one host and one PCIe switching hierarchy.
That does not make the server inherently unreliable. It means replication, erasure coding, spare capacity and rebuild behavior have to treat the chassis as a meaningful failure boundary.
Serviceability matters for the same reason. Hot-swap bays simplify individual drive replacement, but serviceability becomes part of uptime when one enclosure carries 160 primary drives. Accurate drive identification, predictable firmware management and fault isolation become operational requirements, not conveniences.
Power and Cooling Still Set Physical Limits
Flash eliminates spinning media, but 160 NVMe devices packed into a 4U enclosure still generate heat. Add the processor, PCIe switches, DIMMs and network adapters, and airflow becomes part of storage architecture.
Supermicro specifies hot-swappable rear fans and redundant 2,600W supplies while keeping the system air cooled. That makes density attractive where rack space is scarce, but operators still need to validate inlet temperatures, fan behavior and drive thermals under sustained load.
A denser storage tier can also reduce the number of host servers needed for a given capacity target. That may leave more rack positions and facility power available for compute, especially in AI environments where every supporting system competes with GPU infrastructure for electrical capacity.
Networking Can Become the Next Constraint
A server holding this much flash is valuable only if applications can reach the data quickly enough. The onboard pair of 10GbE ports does not define the practical ceiling because the PCIe 5.0 expansion slots can accommodate faster network interfaces, but network design becomes inseparable from storage design.
The same pressure appears in AI memory bandwidth: moving data efficiently matters at every layer, from memory near the accelerator to storage and the fabric connecting servers.
Operators should evaluate the entire path. PCIe-switch contention, NIC bandwidth, storage protocol, CPU overhead and east-west traffic can decide whether 160 drives form a productive shared pool or an expensive capacity island.
Moving the data is the test, not merely fitting it into 4U.
Deployment Data Will Decide Whether Density Pays Off
Production deployments should be judged by aggregate throughput, tail latency, drive temperatures, PCIe-switch behavior and rebuild performance under sustained mixed workloads. Those measurements will show where the architecture trades individual-device performance for density.
Maintenance will be just as revealing. A platform carrying this much capacity needs predictable drive replacement, firmware procedures and node-level data protection so that a single server event does not expose an outsized portion of a storage pool.
The Supermicro 160-bay NVMe server shows the direction of enterprise flash: fewer chassis can hold extraordinary amounts of data, but the pressure moves into I/O, networking and operations. The real achievement will not be putting nearly 20PB into 4U. It will be making that density behave predictably as part of a larger system.
Frequently asked questions
How much storage can the Supermicro 160-bay NVMe server hold?
Using 122.88TB SSDs in all 160 U.2 bays produces about 19.66PB of raw capacity. Actual usable storage will be lower after redundancy, spare capacity and storage-software overhead.
Why are the 160 U.2 bays connected at PCIe 4.0 x1?
Using narrower links reduces the enormous PCIe lane requirement created by 160 drives. The tradeoff enables extreme density while limiting the maximum bandwidth available to each SSD compared with a full x4 connection.
Is the ASG-4116S-NU160R designed for AI workloads?
Supermicro lists AI and deep-learning training among its target applications. Its strongest role is likely as a dense data repository positioned near compute systems that need rapid access to very large datasets.
What are the biggest challenges of running 160 NVMe drives in one server?
PCIe contention, cooling, power consumption, network throughput and failure-domain size all become significant concerns. Operators also need reliable drive identification, firmware management and data-protection strategies for such a dense enclosure.
Does higher storage density automatically mean better performance?
No. Higher density increases capacity per rack unit, but performance still depends on PCIe topology, CPU resources, network bandwidth, storage software and workload behavior. A dense server can become constrained elsewhere in the data path.



