Satisfactory Manifold vs Load Balancer

A manifold — one belt run past a row of machines through chained splitters — reaches full output on every machine with zero planning, as long as the belt feeding it carries at least as much as those machines demand in total. A load balancer needs more splitters, more mergers, and exact ratio math to do the same job, and its only real advantage is skipping the few minutes a manifold takes to fill. That trade-off is why manifolds are the default for roughly 9 out of 10 production lines in this game. The other 10% — fluids, deliberately prioritized outputs, and belt-tier mismatches — is where a load balancer, or a hybrid of the two, earns its keep. Below is the actual mechanism behind that split, the math that tells you when a manifold will starve a machine outright, and the three specific cases where you should reach for a balancer instead.

How a Manifold Actually Balances Itself

Every basic Conveyor Splitter distributes items round robin — one item at a time, cycling through whichever outputs currently have room — regardless of item type or belt speed [1]. That’s the whole mechanism. There’s no hidden priority system and no “smart” behavior in the base Splitter; it just keeps cycling through open outputs and holds up to 9 items internally if every output is blocked [1].

In a manifold, that round-robin cycling runs into backpressure almost immediately. The short belt segment between a splitter and its machine can only hold so many items before it’s full. If the machine downstream consumes slower than the splitter is feeding it, that segment backs up within seconds — and once it’s full, the splitter stops sending items there and routes everything to the next open output instead. The official wiki puts it plainly: “full machines consume only what they need. Once a machine fills up, it cannot accept any more resources, and thus everything ends up where it needs to be” [2]. Machines closer to the source fill first because they’re first in line for the round robin; machines further down look starved for the first minute or two while the ones ahead of them top off. Given enough time, and provided the input and output rates are sufficient, every machine reaches 100% on its own [2] — no configuration required. That conditional clause is doing a lot of work, and it’s the entire subject of the next section.

Belt segments in a manifold splitter chain showing item density fading from fully saturated to empty toward the end of the line — Item density drops the further you look down the chain — not because the manifold is broken, but because upstream machines are still claiming their share first.

The Saturation Math: When a Manifold Starves a Machine For Good

“Given enough time” only holds if total supply meets total demand. Undersupply a manifold and it doesn’t share the shortfall evenly — the machines closest to the source take their full cut first, and whatever’s left goes to the next one in line. If the belt runs dry before it reaches the last machine, that machine gets nothing, permanently, not just a slow ramp-up.

Run the numbers on a real recipe. A Constructor making Iron Plates needs 30 Iron Ingots per minute and outputs 20 Plates per minute [3]. Line up 10 of them on a manifold and total demand is 300 Ingots per minute. Feed that line from a Mk.3 belt, which caps at 270 items per minute [4], and you’re 30/min short. Machines 1 through 9 pull their full 30/min each — that’s 270/min, the entire belt — leaving machine 10 with exactly zero. It will sit at 0% output forever, not because anything is broken, but because there was never enough supply left by the time the round robin reached it. Swap that same line onto a Mk.4 belt (480/min) and there’s 180/min of headroom over the 300/min demand; all 10 Constructors saturate to 100% within a few minutes, exactly as the wiki’s conditional describes [2][4].

Belt tier	Throughput	10 Constructors (300/min demand)	Result
Mk.2	120/min	Covers machines 1–4 only	Machines 5–10 permanently starved
Mk.3	270/min	Covers machines 1–9	Machine 10 permanently starved
Mk.4	480/min	Covers all 10 with 180/min spare	All 10 reach 100% over a few minutes
Mk.5	780/min	Covers all 10 with 480/min spare	All 10 reach 100% faster, belt is over-built

The takeaway the table makes concrete: a manifold’s headroom rule isn’t “make the belt big enough on average” — it’s “make the belt’s rated throughput meet or beat total demand, full stop.” Undersupply by even one machine’s worth of items and that exact number of machines at the tail end gets cut off completely, not slowed down.

This is also where a lesson from Factorio’s train-signal logic carries over almost exactly: throughput bottlenecks in a belt-and-splitter network behave like throughput bottlenecks on a rail network — the constraint always shows up at the narrowest point in the chain, and fixing the visible symptom (the starved machine) does nothing until you fix the actual bottleneck (the belt tier feeding it).

Building a Load Balancer — and Why 10 Machines Is an Awkward Number

A load balancer is the opposite fill method: instead of feeding machines in sequence and letting backpressure sort it out, you nest splitters so every output gets an exactly equal share from the first item onward. A single splitter makes a clean 1:2 split. Nest two of those and you get 1:4; nest three and you get 1:8. The same pattern works in threes — nest 1:3 splitters for 1:9, or combine 2s and 3s for 1:6, 1:12, or 1:18 [5]. Any of those numbers builds cleanly with no wasted throughput.

Ten machines doesn’t factor into 2s and 3s cleanly. Building an exact 1:10 balancer means either an asymmetric tree (a 1:2 stage feeding one 1:5 branch, which itself isn’t a clean power-of-2/3 shape either) or rounding up to the nearest clean number — typically 1:12 via 2×6 — and looping the two unused outputs back into the input, which costs you the throughput those two branches would otherwise have carried [5]. Compare that to the manifold: 10 machines needs one belt and 10 splitters in a straight line, no ratio planning at all. This is the practical reason manifolds dominate at scale — production lines grow by irregular amounts as you unlock new recipes and expand, and a balancer’s ratio math has to be rebuilt (or padded with lossy loopbacks) every time the machine count isn’t a clean power of 2 or 3.

That same “explicit configuration instead of emergent behavior” trade-off shows up in Factorio too: a circuit network in Factorio gives you deliberate, exact control over splitting and routing, in exchange for having to design and wire that logic yourself — the same bargain a Satisfactory load balancer makes against a manifold’s “just place belts and wait.”

What Should You Actually Build? Player-Type Verdict

The right default changes with how far along your save is and how much you’re optimizing for time versus tinkering:

Player type	Default choice	Why
New player	Manifold, always	Zero ratio math, forgiving of mistakes, and the “why is machine 10 at 0%” confusion is the single most common early-game support question — understanding it here saves hours of confusion later
Casual player	Manifold, oversized belt by one tier	One tier of headroom above calculated demand avoids the exact starvation case above without doing precise math every time
Hardcore / optimiser	Manifold for anything expandable, balancer only where instant 100% output matters (train station loading, sink arrays)	Balancers cost extra buildings and floor space for a benefit — a few minutes of ramp-up time — that rarely matters once a factory is running 24/7
Completionist / megabase builder	Manifold on every belt tier of the main bus, balancer only for pipeline loopback and priority-merger logic	At megabase scale, a balancer’s loopback throughput loss compounds across dozens of branches; manifolds scale linearly with zero rebuild cost when you add another production line

As a decision rule: if you’re about to place a splitter and you don’t already have a specific reason to force an equal split, build the manifold. Only reach for a balancer when one of the three cases below actually applies.

The 10% Where the Load Balancer Wins

Infographic showing the three scenarios where a load balancer beats a manifold in Satisfactory: fluids, mixed-rate outputs, and belt-tier mismatches — The three genuine exceptions to “just build a manifold” — everything else defaults to the simpler option.

Fluids. Pipe manifolds work on the same self-balancing principle as belt manifolds, but the wiki is explicit that “you cannot construct a pipeline balancer” for fluids at all [6] — the choice for pipes isn’t manifold-versus-balancer, it’s manifold-versus-nothing. The catch is reliability: Junction Crosses cause flow to drop once too many machines are drawing from the same manifold, and the fix is a loopback pipe — a secondary line split off the main feed and merged back in at the far end of the manifold [6]. Build pipeline manifolds with a loopback from the start on anything feeding more than 3–4 machines, and don’t plan a fluid line to run at its pipe tier’s rated maximum; junction flow-drop eats into that margin.

Mixed-rate, priority-driven outputs. A plain manifold’s fill order is decided entirely by physical position — whichever machine is first in line gets fed first, whether or not that’s actually the machine you care about most. When you need a specific machine fed before the others on purpose — say, a train station’s input buffer topped off before the overflow goes to a sink — that’s a job for a Priority Merger, which lets you set each input to low, medium, or high and exclusively drains the highest-priority input first [7], or a Smart Splitter, which filters and routes by rule per output in a fixed center-left-right order [8]. Neither of these is a symmetric load balancer in the classic sense, but they solve the same underlying problem a balancer solves: taking allocation out of the hands of physical position and putting it under your explicit control.

Belt-tier mismatches. The saturation math above assumes the main belt and the side belts running into each machine are all capable of carrying what’s asked of them. If your main line is a Mk.3 (270/min) but the belts running the last stretch into each machine are Mk.1 (60/min each), a plain manifold can stall even with enough total supply, because a single Mk.1 segment physically can’t carry more than 60/min to that machine no matter how much is queued up behind it. The fix is a hybrid “injected manifold” — Smart Splitters configured to push a fixed amount onto each branch rather than relying on round robin alone [2]. This is the one case where the fix isn’t “swap to a balancer,” it’s “add balancer-style explicit configuration on top of an otherwise normal manifold.”

Scenario	Build this	Skip if
Standard production line, any size	Plain manifold	You need instant 100% output the moment power comes on
Fluids of any kind	Pipeline manifold with loopback	You’re running the pipe at its rated max — build in margin instead
Train station / storage array feed	Load balancer, or Priority Merger if one input matters more	The line will grow later — a manifold survives expansion better
Main belt tier > branch belt tier	Hybrid injected manifold (Smart Splitters)	Every belt segment in the chain matches the main line’s tier — then a plain manifold is enough

Common Manifold Mistakes That Look Like Bugs

A machine stuck at 0% in a manifold almost never means the setup is broken — it means the belt feeding it can’t cover total demand, exactly as in the Mk.3-with-10-Constructors example above. Before troubleshooting anything else, add up every machine’s input rate on that line and compare it to the belt’s rated throughput [4]; if demand exceeds supply, either upgrade the belt tier or remove a machine, not just wait longer.

The second common trap is assuming a Smart Splitter’s three outputs get checked in the order they’re placed on screen. They don’t — the game always evaluates center output first, then left, then right, regardless of build order [8]. If your priority routing looks backwards, check which physical output is wired to “center,” not the order you clicked things in.

Frequently Asked Questions

Why is the last machine on my belt stuck at 0% even though everything looks connected?

Your belt’s total throughput is lower than the combined demand of every machine on the line. The machines closest to the source take their full share first; whatever’s left over goes to the next one, and if nothing’s left by the time the belt reaches the end, that machine gets nothing. Upgrade the belt tier or move a machine to a different line — waiting longer won’t fix it if supply is genuinely short.

Do I need a load balancer for a coal power setup?

Not for the generators themselves — a properly headroom-sized manifold saturates a coal generator row the same way it saturates any other machine line, which is exactly how an 8-generator, 3-extractor coal water ratio is built. Where balancing matters more is the water supply if you’re feeding generators from multiple extractors on pipes rather than a single water source.

Can I mix manifolds and load balancers in the same factory?

Yes, and most efficient factories do. Use a manifold for the bulk of a production line, then drop in a small balancer or Priority Merger only at the specific junction where you need guaranteed equal or prioritized output — there’s no rule requiring one style for an entire base.

Does a manifold waste items if a machine downstream is already full?

No. Once every reachable output is backed up, the feeding splitter simply stops pulling more items off the belt behind it — nothing is deleted or wasted, it just queues further back up the line until somewhere downstream opens up again [1].

Is any of this different if I’m running a heavily modded or performance-limited setup?

The splitter and belt mechanics themselves aren’t affected by mods or frame rate, but a factory this size can still tax your GPU well before your CPU becomes the bottleneck — if your factory is chugging while you’re placing splitters, check your Satisfactory PC settings before assuming the belt logic itself is the problem.

Sources

Michael R.

I've been playing video games for over 20 years, spanning everything from early PC titles to modern open-world games. I started Switchblade Gaming to publish the kind of accurate, well-researched guides I always wanted to find — built on primary sources, tested in-game, and kept up to date after patches. I currently focus on Minecraft and Pokémon GO.