What each option really is
A PoE injector is a midspan: one non-PoE switch port in, one powered port out, data untouched. It adds standards-based power to exactly one link. A PoE switch replaces the switch itself, powering every port. The comparison is therefore not device vs device — it is one-at-a-time power vs power as infrastructure, and the right answer changes with device count, clustering and how the network will be operated.
Start with the case for injectors, which is stronger than switch vendors admit. For a single camera or access point added to an existing non-PoE network, an injector (ONV's gigabit model delivers 30W of 802.3 af/at in a 104 × 50 × 29 mm body) is cheaper, faster and touches nothing else. For a bt-class PTZ on an at switch, one bt injector beats replacing the switch. For the far end of a fiber link, an injector is not an option but the architecture — fiber carries no power, so power must be added where the copper resumes.
Where injectors stop scaling
Each injector is a box, a power adapter, two patch leads and a mains socket. Multiply by eight and the cabinet becomes a shelf of wall-warts with eight independent failure points and no central view of anything. Nobody can restart injector #6 remotely, schedule it, or see its load. The crossover in pure hardware cost sits around three to four devices in one place; the crossover in sanity arrives sooner. A small PoE switch centralises power supplies (one built-in PSU), cabling (one row of ports) and — at the managed tier — visibility and remote per-port restart.
Clustering is the multiplier: four cameras in four different buildings are four honest injector cases. Four cameras on one wall are a switch case wearing an injector costume.
The middle patterns worth knowing
Real estates mix the tools. A managed PoE core with injectors reserved for exceptions (the one bt device, the one far-end fiber tail). PoE extenders where the problem is distance rather than count. Splitters at the device end where the device itself lacks a PoE input — the injector's mirror image. And the watchdog question cutting across all of it: unmanaged switches with automatic recovery may serve a scattered camera estate better than either a managed switch nobody watches or injectors nobody can reach.
Decide by three counts: devices per location, locations, and who responds when one dies. One device per location, no operator: injectors and watchdog switches. Clusters with an operator: PoE switches, managed. Clusters without: PoE switches, AI/watchdog class. The tools are cheap; the site visits are not.
Failure domains: the argument nobody prices
There is a quieter difference between the two options that only appears on the maintenance log: what fails together. A PoE switch is one power supply feeding many devices — its failure is large and obvious, and it is usually covered by a spare unit on the shelf. Injectors fail one at a time, silently, in scattered cabinets, and each failure is a separate diagnosis trip to a device that 'just stopped'. Estates with dozens of injectors often discover, a year in, that they have bought a distributed failure domain with no monitoring — the most expensive kind.
The counterweight is real too: a switch concentrates risk, and a failed core switch in a single-box design takes the segment with it. The mature designs therefore look like this: PoE switches where devices cluster (with the failure domain accepted and spared), injectors where devices are genuinely alone, extenders where distance is the problem, and a written note — in the project file — of which choice was made where, and why. The tools were never the hard part; remembering the reasoning is.
Worked example: the eight-camera warehouse that bought both
A small warehouse, eight cameras: four inside on a non-PoE gigabit switch already owned, four outside on poles 60–90 metres from the building. The inside four are one cluster — a compact 8-port PoE switch replaces the tangle before it forms, and its spare ports take the two access points everyone forgot to list. The outside four are four separate locations, each beyond economical switch consolidation, each fed from a nearby cabinet: four honest injector cases, one per pole, fed from the local non-PoE drops. Total purchase: one small PoE switch and four injectors — less than either pure answer (a big switch plus long home-run cabling, or eight injectors and eight adapters to babysit).
What makes the example worth printing is that neither dogma produced it. 'Always switches' overbuilds the poles; 'injectors are cheaper' underbuilds the cluster and mortgages the maintenance. The deciding questions were the three counts from earlier — devices per location (four and one), locations (two kinds), and the responder (a facilities manager who would rather restart a switch port than climb to an injector). Purchases made by those counts survive contact with the building; purchases made by slogan do not.
The decision, compressed
Count devices per location. One, in a place of its own, with power nearby and nobody depending on its uptime beyond a site visit's acceptability: an injector is the proportionate tool, and buying a switch for it is waste. A cluster — three or more in one cabinet's reach: a PoE switch, at the management tier your operating model honestly supports. In between, let the responder decide: whoever will drive out when it dies gets a vote weighted by the drive. Write the count and the choice into the project file; the next expansion will thank you for the reasoning, not just the result.
One last practical note on spares: whichever side of the crossover a location lands, the spare shelf should mirror it — one spare injector of each class in service, or one spare switch of the deployed model, but never neither. The economics are asymmetric in the extreme: an injector costs less than the van roll it replaces, and a switch on the shelf converts a network-down emergency into a twenty-minute swap. Estates discover their spares policy on the worst possible day; write yours on a good one, stock it, and review it whenever the device counts change — which is to say, whenever this guide's three counts change.
There is a final, human consideration: who understands the estate. A switch-centric design concentrates knowledge in one interface a successor can learn; an injector-scattered design distributes it across cabinets, adapters and memory. Neither is disqualifying — small estates run on memory all the time — but the day the person who 'just knows' leaves, the estate's true architecture is revealed. Document the counts and the choices, and either architecture survives its author. That, more than the hardware delta, is what the crossover calculation is really pricing.