What “managed” actually buys you

An unmanaged switch is a dumb box. Plug ports in, traffic flows, no configuration exists, no way to see what’s happening. That’s fine for a single flat network with no segmentation needs, and plenty of small homelabs never outgrow it.

A managed switch gives you a real configuration interface (web UI, CLI, or both) and, critically, the ability to control how traffic moves instead of just letting it flow. The features that actually matter for a homelab, in rough order of how often you’ll reach for them:

VLANs. The single biggest reason to go managed. Without VLAN support at the switch, any VLAN-aware bridge you build in Proxmox is talking to a switch that has no idea what a tag is, and your segmentation stops at the host. If you’ve read the Proxmox networking article on this site, everything in it assumes the switch on the other end of the cable can actually pass tagged traffic on a trunk port and put untagged traffic on the right access VLAN. An unmanaged switch can’t do either.

Link aggregation (LACP). Bonding two or more physical links into one logical one, for either redundancy or (with the right hashing) some additional throughput. Useful on a NAS or a Proxmox host with spare NICs, effectively useless without switch-side support for the same bond.

Port mirroring (SPAN). The ability to copy traffic from one port to another so you can run a packet capture or an IDS without inserting anything inline. Not something you’ll use daily, but the one feature that’s genuinely impossible to bolt on after the fact if the switch doesn’t support it.

Per-port statistics and diagnostics. Real-time throughput, error counters, and link status per port. This is what turns “the network feels slow” into “port 6 has a duplex mismatch and is throwing CRC errors,” which is the difference between guessing and actually fixing something.

Spanning Tree (STP/RSTP). Prevents a switching loop from taking down your entire network if you (or a house guest) accidentally plug a cable into two ports on the same switch, or between two switches, creating a loop. This sounds like an edge case until it happens once, and then it becomes the feature you’re most grateful exists.

QoS / traffic prioritization. Lets you make sure something latency-sensitive (VoIP, a game console, a management VLAN) doesn’t get starved by a bulk backup job saturating the same uplink. Lower priority for most homelabs than VLANs or LACP, but worth having if the switch offers it for free.

The feature checklist, in buying order

Work through these roughly in this order when comparing switches, since each one either is or isn’t a hard requirement, and the hard requirements should eliminate options before price does.

1. Port count and speed mix. Count what you actually need to plug in today, then add headroom, because you will add more devices than you think. Decide how many ports need to be 2.5GbE/10GbE versus plain gigabit; most homelabs are well served by a switch with a handful of faster uplink/server ports and a larger bank of gigabit ports for everything else, rather than paying for 10GbE across every port.
2. VLAN support, and specifically 802.1Q tagging with trunk ports. Confirm the switch supports tagged VLANs on a port at the same time as untagged traffic for the native VLAN, not just “port-based VLANs” that some cheap switches call VLANs but that don’t actually do 802.1Q tagging. This distinction trips people up constantly when comparing budget switches.
3. PoE, if you need it. Access points, some cameras, and a handful of other homelab-adjacent devices want Power over Ethernet. Decide this up front, since PoE switches cost meaningfully more and it’s not something you bolt on later without buying a different switch.
4. Fanless vs. actively cooled. Covered in more detail below, but decide this before you fall in love with a specific model, since it eliminates a lot of options immediately depending on where the switch will actually live.
5. Management interface you’ll actually use. A clean web UI matters more than a CLI for most homelabbers. If you’re already running other gear from a specific ecosystem (Ubiquiti’s UniFi controller, for instance), staying in that ecosystem for the switch too usually means one pane of glass instead of three.
6. Firmware update track record. Not glamorous, but it matters. A vendor that’s still shipping firmware updates for hardware from five years ago is a very different long-term bet than one that stops supporting a model the year after it ships.

Fanless vs. rackmount: this decision matters more than the spec sheet

Where the switch physically lives should shape the decision before feature lists do. A switch in a closet, a basement corner, or anywhere near a desk needs to be fanless or near-silent, full stop. Small desktop and rack-mountable switches with actively cooled 10GbE or PoE ports can be genuinely loud, and that’s not something you notice from a spec sheet, only from actual reviews or, worse, after it’s already installed somewhere you can hear it.

If the switch is going into an actual rack in a dedicated space (a garage, a basement utility room, a closet with the door usually closed), fan noise stops mattering nearly as much, and that opens up a much wider field of used enterprise gear, which tends to be louder but meaningfully cheaper per port, especially for higher port-count or SFP+-heavy switches.

Ubiquiti vs. MikroTik vs. used enterprise gear

These are the three paths most homelabbers end up choosing between, and each is a genuinely different tradeoff, not just a different price point.

Ubiquiti (UniFi line). The easiest on-ramp for VLANs, and the most polished web UI of the three by a wide margin. If you’re newer to managed switching or you want a controller-based setup that also manages APs and gateways under one login, UniFi is the path of least resistance. The tradeoff is a real ecosystem lock-in: the UniFi Network application wants to manage the whole stack, and stepping outside it for one piece of gear is more friction than with a standalone switch.

MikroTik. More configuration depth and typically better price-per-port than Ubiquiti, especially on SFP+-heavy models, but the RouterOS interface (Winbox, or the web UI) has a real learning curve and the terminology doesn’t map cleanly onto what most guides assume. Worth it if you want to actually learn networking rather than just get VLANs working, and MikroTik hardware has a strong reputation for running for years without drama once it’s configured correctly.

Used enterprise gear (Cisco, Juniper, Dell/Force10, Arista). The same used-market value play covered in the used-enterprise-gear buying guide on this site applies directly to switches. You can land serious port density and SFP+ capability for a fraction of new pricing, but budget real time for the CLI learning curve on Cisco IOS or similar, be honest with yourself about fan noise (most of this gear was built for a data center, not a bedroom closet), and check End-of-Life/End-of-Support status before buying, since a switch that stopped getting security patches years ago is a real risk to put anywhere near the rest of your network, not just an inconvenience.

A simple way to decide

Start from where the switch will physically live, since that alone eliminates a chunk of the field on noise grounds. From what’s left, confirm real 802.1Q VLAN tagging support, since that’s the one feature that’s genuinely non-negotiable if you’re running Proxmox with any kind of network segmentation. Then pick the ecosystem that matches how much you want to learn versus how much you want to just click through a clean UI and move on: UniFi for the smoothest experience, MikroTik for better value and more control if you’re willing to climb the curve, and used enterprise gear if you have a quiet-enough space for it and want the most port density per dollar. Any of the three will run a homelab well once it’s configured; the mistake that actually costs you time later is buying on port count and price alone and discovering only after the fact that the switch you bought can’t actually tag a VLAN the way your Proxmox bridge expects it to.