You are out of disk. The instinct is to buy another server, but that is often the expensive answer to the wrong question. If the existing host still has spare CPU, memory and controller headroom, bolting on a JBOD expansion shelf adds terabytes for a fraction of the cost and complexity of a whole new node. If it does not, a JBOD just moves the bottleneck. Knowing which case you are in is the difference between a cheap capacity top-up and an avoidable second server, and this is the framework we use to decide.
The two ways to grow
There are two clean ways to add storage capacity to an existing estate. The first is a JBOD: a shelf of drives with no compute of its own, daisy-chained to a host over SAS through an HBA, so the existing server drives the new disks. You pay for drives and a shelf, not for another set of CPUs, memory, licences and management overhead.
The second is another server: a fresh node with its own compute, memory, network and drives. You pay considerably more, but you also get more of everything, and in a scale-out storage cluster a new node adds performance as well as capacity. The right choice turns entirely on whether your bottleneck is capacity alone or capacity plus the compute to serve it.
Start with headroom on the existing host
The first question is whether the current host has headroom to drive more drives. A JBOD adds spindles or flash, but those drives still consume CPU cycles, memory and controller bandwidth on the host they hang off. If the existing server is already busy on CPU, short on RAM, or near the limits of its storage controller, adding a JBOD loads a system that is already at its edge and performance suffers.
Check the controller path specifically. Every HBA and SAS expander has a finite number of devices and a finite bandwidth, and a JBOD chain has to fit inside those limits. If the host has spare cores, free memory and controller capacity to spare, a JBOD is the efficient choice. If it is maxed out, the honest answer is that you need more compute, which means a server. Our host bus adapters range is where that controller headroom is decided.
- •Spare CPU, RAM and controller bandwidth on the host -> JBOD is the efficient top-up
- •Host already busy or near controller limits -> a JBOD just moves the bottleneck
- •Need more performance, not just capacity -> a new node, especially in scale-out
- •Always check HBA and expander device and bandwidth limits before chaining a shelf
Capacity-bound versus compute-bound growth
The cleanest way to frame the decision is capacity-bound versus compute-bound. Capacity-bound growth is when you simply need more terabytes for data that is not especially demanding to serve, such as a backup target, an archive or a nearline tier. A host with headroom plus a JBOD is almost always the cheaper, simpler answer, and it can be the right answer several times before you run out of room.
Compute-bound growth is when the new data also needs more performance to serve it, or when the host is already working hard. Here a JBOD would just pile load onto a saturated system, and a new node, which brings CPU, memory and network alongside the drives, is the correct call. In a scale-out cluster that node also improves the whole system, since capacity and performance grow together, a pattern we explore in scale-out vs scale-up storage.
The cost curves diverge
The economics make the choice stark. A JBOD adds incremental capacity at close to the cost of the drives, because you are reusing the compute, network and management you already own. The cost per usable terabyte of expansion is low, which is exactly why dense storage platforms are designed to chain shelves rather than force a new server for every growth step.
A new server carries the full cost of a node: silicon, memory, network, often licensing, and ongoing power, rack space and management. Per terabyte it is the more expensive path, justified only when you genuinely need the compute it brings. The trap is buying a node when a shelf would do, paying for cores and licences you do not need just to land some disk.
Resilience and the limits of chaining
A JBOD also concentrates more eggs in one basket: more drives now depend on a single host and its controller, so a host or controller failure takes a larger pool offline. That is fine for data protected by replication, erasure coding or backups, but it argues against piling ever more capacity behind a single point of failure for primary data. There is a practical ceiling to how far you should chain before resilience, not cost, says stop.
A new node spreads risk: in a clustered design, losing one node leaves the others serving while the system self-heals. So beyond the cost question there is a resilience question, and the two often point the same way once a single host is carrying a great deal of capacity. We weigh both when we design expansion in our server configuration service, sizing controllers, shelves and nodes to the failure model you need.
Putting it together
Audit the existing host first: if it has spare CPU, memory and controller bandwidth and the growth is capacity-bound, add a JBOD and save the cost of a node. If the host is busy, the growth is compute-bound, or you are pushing a single point of failure too far, buy the server. For the mechanics of JBOD chaining and SAS expansion read host bus adapters, and for choosing the media that fills either path see HDD vs QLC vs TLC tiering.