For twenty years the answer to “how do I connect servers to the array” had two acceptable forms. Fibre Channel if you were serious, iSCSI if you were not, and a long-running argument between the two that generated more heat than insight.
That argument is now mostly over in the mid-range, and the thing that ended it was not a performance benchmark.
The honest performance picture
NVMe over Fibre Channel is excellent. NVMe over TCP is very good. On raw latency, Fibre Channel retains an advantage, and if you have a workload where a few tens of microseconds is the difference between meeting and missing a target, that advantage is real and you should buy it.
Most workloads are not that workload. For a mid-range estate running databases, virtual machines and applications, the latency difference sits well inside the noise created by everything else in the stack. Once the difference stops being visible to the application, it stops being a purchasing criterion.
What actually decided it
Three things, none of them latency.
One network instead of two. A Fibre Channel SAN is a separate physical network with separate switches, separate optics, separate firmware lifecycles and separate change windows. Removing it removes a whole column from the build sheet and a whole category of “who do I call”.
One skill set instead of two. This is the real one. Zoning is not difficult, but it is specialised, and the people who are genuinely good at it are retiring faster than they are being replaced. I have been in more than one organisation where the SAN was maintained by exactly one person, and the succession plan was a wiki page that had not been updated since 2019. Moving to Ethernet does not eliminate the skill requirement, it converts it into a skill the organisation already has several people for.
Ethernet’s economics. Port for port, at the speeds that matter, Ethernet moved faster and cheaper. That has been true for a while and it compounds.
Where the difficulty moved to
None of this is free. The complexity did not disappear, it changed shape.
Fibre Channel gave you a lossless network by construction. On Ethernet you have to configure one, and the configuration has to be consistent across every switch in the path. Flow control, congestion notification, buffer settings. Get it partly right and you get a fabric that works under light load and degrades under the exact conditions you built it for.
You also inherit the ordinary hazards of a shared Ethernet network. A misconfigured trunk somewhere unrelated can now affect storage. On a dedicated SAN that was impossible by physics. So: dedicated VLANs at minimum, dedicated switches where the budget allows, and a written rule about what may share the storage fabric.
Multipathing works but is worth testing properly rather than assuming. Pull a cable during commissioning and watch what the host does. Do it before production, because the answer is occasionally surprising and always better discovered early.
Where Fibre Channel still belongs
I want to be clear that this is not an obituary. There are good reasons to keep or choose Fibre Channel:
You already have it, it works, your team knows it, and the array refresh does not force a change. Inertia is a legitimate engineering argument when the incumbent is reliable.
You have a genuine hard-latency requirement with a number attached to it. If somebody can tell you the number, believe them and buy the right thing.
Regulatory or audit reasons that favour a physically separate storage network. These exist and arguing with them is not productive.
The advice I give
If you are building new in the mid-range in 2026, NVMe/TCP should be your default and Fibre Channel should have to justify itself, which is a reversal of where that burden of proof sat five years ago.
But budget the network engineering. The mistake I see is treating “it is just Ethernet” as meaning “it needs no design”. It needs design, it needs a commissioning test plan, and it needs someone who owns it. The thing you saved was not effort, it was a separate technology stack. That is still a very good trade.