AI and the hyperscalers are consuming the world’s supply of HDDs, RAM, and CPUs, lead times are stretching, and prices keep climbing with nothing in the current data suggesting a reversal this year.
At the same time, surveillance keeps asking for more, with 5 to 8MP now standard and 15 FPS still the baseline most projects get quoted at, a combination that wants roughly twice the storage and processing it did a few years ago, right as the underlying hardware costs more to buy.
The instinct when storage gets expensive is to hand the problem to someone else, push everything to the cloud and let a provider absorb the cost, but that instinct is wrong, or at least incomplete. Cloud storage isn’t insulated from the same drive market driving up on-prem costs, since the provider is buying the same disks you are, and that gets passed through in per-GB and egress pricing over time. Uploading continuous 5 to 8MP video also needs WAN bandwidth most sites don’t have, so the storage cost just becomes a connectivity cost instead. Hybrid, hot footage local and older footage archived selectively, is usually the honest answer, since all-cloud is rarely the free pass it looks like on a slide.
The better response is designing the project correctly instead of routing around the problem.
Push intelligence to the camera before it hits the server
The cheapest byte to store is the one you never write. Cameras with onboard motion detection and object classification, person or vehicle versus a tree branch moving, filter out what isn’t worth recording before it reaches the server at all, and every false trigger eliminated at the camera is storage and processing you never had to buy downstream. Analytics are increasingly running at the edge industry-wide, handing the server metadata and flagged frames instead of raw video, so the server spends its cycles on targeted work instead of sifting everything itself.
Turn on H.265
This lever costs nothing: same image quality, meaningfully less data, and on a platform built to run it at full stream count, no camera-count penalty to pay for it. At 4MP and 15 FPS, a typical scene runs around 4.4 Mbit/s in H.265 versus about 7.5 Mbit/s in H.264, roughly 40 percent less data for the same picture, and since storage scales directly with bitrate, that’s a 40 percent cut to the recording array before you’ve touched a single other setting.
If your current platform takes a real camera-count hit switching to H.265, that’s a platform problem rather than a codec problem. VideoX runs on AMD, which handles H.265 substantially more efficiently than the Intel Xeon generations most competitors are still built on, and the max camera counts published for VideoX servers are already H.265 numbers with headroom to spare.
Every other lever below involves a judgment call, this one doesn’t, so turn it on for every project, every camera, no exceptions.
Stop defaulting to native resolution
An 8MP lens doesn’t mean the scene needs to record at 8MP. Match resolution to the pixels-per-foot the scene actually requires at its real working distance, and at most distances, 4 to 5MP identifies a face or a plate as well as 8MP while storing a fraction of the data. The era of speccing every camera to its maximum “just in case” is ending industry-wide, because the economics no longer support padding a project that doesn’t need it.
Treat frame rate as its own dial
Fifteen FPS is still the default most cameras ship at and most quotes assume without a second look, but it doesn’t need to be. Smart partners are already moving mid-value scenes, interior common areas, secondary entrances, hallways, down to 12 or 13 FPS, where a person walking or a vehicle moving still tracks cleanly, and truly low-activity scenes like storage rooms or back-of-house areas can drop to 10 FPS. Bitrate scales roughly with frame rate, so this stacks with H.265 and resolution rather than repeating their savings.
Move to motion-only recording, with real buffers
Motion-only recording cuts storage hard on the right scenes, but done carelessly it loses the first second or two of an incident, exactly when it starts. A pre-buffer that continuously caches a rolling window and commits it once motion confirms solves that, and a post-buffer prevents premature cutoff when motion dips mid-event, someone pausing, a vehicle idling. Done right, motion-only with generous buffers on appropriate cameras cuts storage well beyond what codec and resolution changes alone deliver, without losing anything a reviewer would actually need.
Ask about retention before you assume it
Retention is different from the levers above, since it’s a compliance and business question rather than a camera setting. Some verticals carry hard floors, banking, cannabis, and casinos often require 90 days or more, and those don’t move, but a lot of projects inherit 30 or 60 days out of habit rather than requirement. Asking the customer’s actual compliance contact what the real minimum is, rather than assuming, sometimes trims real capacity off zones that never needed the padding.
What it looks like stacked together
Here’s a 300-camera project, mixed interior and exterior, run through the same bitrate and motion logic behind the Arxys calculator:
| What you apply | Storage Needed | Cumulative Reduction | Storage Servers Needed |
|---|---|---|---|
| Baseline: H.264, native resolution, 15 FPS continuous, 30-day retention | 1,069 TB | N/A | 5 |
| + H.265 enabled | 627 TB | 41% | 3 |
| + Right-sized resolution | 533 TB | 50% | 3 |
| + FPS dial-back (fleet-weighted ~13 FPS) | 455 TB | 57% | 3 |
| + Motion-only recording with pre/post buffer | 278 TB | 74% | 2 |
| + Retention right-sized to actual requirements | 239 TB | 78% | 2 |
(Illustrative math using our calculator’s bitrate and motion-weighting logic; run your own project for exact numbers.)
Same camera count, same coverage, three fewer storage servers, and that’s the whole argument in one table: sizing a project correctly means recommending less hardware, which is a stronger thing to put in front of a customer than any spec sheet padded to the maximum.
The guardrail
H.265 is the only lever here with zero cost, everything else, resolution, frame rate, motion-only, retention, is a tradeoff, and tradeoffs need judgment rather than a blanket setting applied to every camera on a project. Entrances, cash handling areas, and anywhere a customer’s insurer or auditor has a stated requirement should stay on continuous recording at full resolution regardless of what the drive market is doing. The goal is cutting where a scene doesn’t need what it’s getting, while holding the line where it does.
One more lever, on the purchasing side
Multi-sensor cameras don’t change the storage math, since four sensor heads on one unit still produce four streams and still cost four streams’ worth of bitrate. What they change is hardware count, since one multi-sensor unit replacing three or four single-sensor cameras collapses licensing, mounting, and cabling costs even as the recording load stays roughly the same. You buy precisely what the project needs instead of defaulting to more, and the Arxys portal calculator now supports multi-sensor camera models directly, so that math is built into the sizing from the start.
Run your next project through the calculator with these settings in place and see what the system actually needs, since it’s usually smaller than the default quote, and that’s the point.
