Sizing video surveillance storage and bandwidth before you buy cameras

Reference article · 6 min read

Storage and bandwidth for a video surveillance system are settled by arithmetic, and that arithmetic can be done before anyone picks a camera model. The inputs are camera count, the bitrate each camera produces, how many hours a day each camera records, and how many days you keep the video. Compression technology, analytics, and camera brand change the bitrate you plug in, not the structure of the calculation.

Doing the math early matters because the two expensive mistakes both happen at purchase. One is buying cameras and then discovering that the recorder, the closet uplinks, or the circuit cannot carry them. The other is accepting a storage estimate built on assumptions about scene activity that do not match your parking lots at shift change.

Start with bitrate, not megapixels

Resolution by itself does not determine how much data a camera sends. Bitrate does, and bitrate depends on several factors at once:

Resolution and frame rate. These set the ceiling. Dropping from 30 fps to 15 fps generally reduces the stream substantially, and for most fixed-scene evidentiary use, 15 fps or lower is defensible.
Codec. H.265 typically produces smaller streams than H.264 at comparable quality, and vendor "smart codec" modes reduce it further by lowering quality in static regions. Confirm that your video management system, browsers, and client workstations decode whatever you select.
Scene content and lighting. An empty interior hallway compresses well. A tree line in wind, a busy intersection, or a noisy low-light image at night can multiply the same camera's output.
Bitrate control. Constant bitrate is predictable and easy to size. Variable bitrate averages lower but has peaks. Capped variable bitrate gives you a ceiling you can plan against.

Ask vendors for measured bitrate at the exact settings you intend to run, not a datasheet maximum, and require a cap.

The arithmetic in one line

One megabit per second recorded continuously for a full day is about 10.8 gigabytes, because 1 Mbps is 0.125 megabytes per second and a day has 86,400 seconds. From that:

Storage in GB = cameras x Mbps x 10.8 x (recording hours per day / 24) x retention days

Decide early whether you are speaking in decimal terabytes, which is how drives are usually sold, or binary tebibytes, which is what many operating systems report. The gap is large enough at scale to cause an argument at acceptance.

A worked example: 200 cameras, 30 days

Assume 200 cameras at 4 MP, 15 fps, H.265, capped variable bitrate, recording continuously, and a planning figure of 3 Mbps per camera. Treat that 3 Mbps as an assumption to be replaced with measured values, not a fact.

Per camera per day: 3 x 10.8 = 32.4 GB
All 200 cameras per day: about 6.5 TB
Thirty days of retention: roughly 194 TB of video

That is video only. Raw disk must be larger, because RAID parity, hot spares, file system overhead, and the practice of not running arrays to full consume capacity. Add room for audio, metadata, analytic snapshots, the VMS database, and evidence exports that are held outside the normal retention window. Then test the assumption: at 4 Mbps the same system needs closer to 259 TB, and at 2 Mbps closer to 130 TB. Bitrate, not camera count, is the variable most likely to break your estimate.

Motion recording saves less than expected

Event or motion recording reduces storage in proportion to how much of the day actually triggers, and that fraction is usually higher than planners assume. Pre-roll and post-roll buffers extend every event. Cameras aimed at roadways, waiting areas, or anything that moves in wind may record nearly continuously. A common compromise is continuous recording at reduced frame rate with full frame rate on event.

Validate with a pilot: run a representative sample of cameras at production settings for a full week including nights and weekends, and read actual recorded bytes. Design so that a wrong assumption shortens retention rather than silently dropping recordings, and monitor the days of retention you are actually achieving.

Where the traffic actually lands

Camera to recorder. In the example, 200 cameras produce roughly 600 Mbps of continuous ingest. If recorders sit in the same building, that traffic never leaves the local switches.
Closet uplinks. Count cameras per access switch, multiply by capped bitrate, and compare to the uplink. Also check the Power over Ethernet budget, since heaters and pan-tilt-zoom units draw far more than fixed domes.
Backbone. If recording is centralized, every stream crosses the campus or metro link all day, every day.
Viewing and retrieval. Live walls and investigative playback pull streams back out of the recorder. A large monitoring wall can generate as much traffic as a group of cameras.
WAN to a cloud VMS. This is sustained upstream traffic. Compare it to the circuit's upload speed, not its download speed, and ask about contention and any data volume limits.

Cloud hosted options and the contract questions

Before comparing a cloud subscription to on-premises hardware, get these in writing:

Licensing unit. Per camera, per channel, or tiered by resolution, frame rate, or retention. Confirm how a camera upgrade changes the tier.
Retention pricing. How many days are included and what each additional camera-day costs.
Egress and export fees. Public records requests and discovery can require bulk retrieval. Ask what a large export costs and how long it takes.
Edge buffering. Whether devices keep recording and backfill when the WAN drops, and for how long.
Exit terms. How you get video out at the end of the term, in what format, and who pays.

Then require, in the solicitation, that the vendor state the bitrate assumption behind its storage number and warrant the retention period at a capped bitrate. Ask for a network diagram showing every link the video crosses. Size for the cameras you expect to add, and confirm retention requirements with your records officer or counsel, since retention schedules vary by state and by record type and do change.

HQT works with state and local agencies on systems engineering and infrastructure planning of this kind, including capacity modeling and requirements development.

Frequently asked questions

How much storage do I need for 200 cameras with 30 days of retention?

There is no single answer, because storage depends on bitrate rather than camera count alone. As a planning method, multiply cameras by megabits per second, then by 10.8 gigabytes per day for continuous recording, then by retention days. At a 3 Mbps assumption, 200 cameras recording continuously for 30 days is roughly 194 TB of video, and raw disk must be larger to cover RAID overhead, spares, and headroom.

How do I convert camera bitrate to gigabytes per day?

One megabit per second recorded continuously produces about 10.8 gigabytes per day, since 1 Mbps equals 0.125 megabytes per second across 86,400 seconds. Multiply that by the camera's capped bitrate to get per-camera daily storage, then by camera count and retention days. Adjust for recording hours if cameras do not run 24 hours.

Does motion-based recording actually cut storage requirements?

It can, but the savings depend entirely on how often the scene triggers, and pre-roll and post-roll buffers extend every event. Cameras facing roadways, waiting areas, or vegetation may record almost continuously. Run a pilot at production settings for a full week, including nights and weekends, and size from measured results rather than an assumed duty cycle.

What bandwidth does a cloud video management system need?

Roughly the sum of all camera bitrates, sustained upstream, for as long as cameras are recording. Two hundred cameras at 3 Mbps is about 600 Mbps of continuous upload, which is the figure to compare against the circuit's upload capacity rather than its download speed. Ask the vendor about edge buffering during outages and whether upload can be shaped during business hours.

What should we require from vendors in a surveillance storage solicitation?

Require the vendor to state the bitrate assumption behind every storage figure, at the resolution, frame rate, and codec you intend to run, and to warrant the retention period at a capped bitrate. Ask for a network diagram showing each link the video crosses, including closet uplinks and any WAN segment. For hosted options, get licensing unit, included retention days, export and egress costs, and end-of-term data return in writing.